[meta-xilinx] SSH Help

[Martin Townsend]

I've found the problem, it was the external toolchain I'm using (SDK 
2013.3). I've switched to using the one that gets built for poky (using 
the dora branch) and the openssh server now works :)

Cheers,
Martin.


On 13/12/13 09:18, Martin Townsend wrote:
> Hi Nathan,
>
> Thanks for the swift reply.  I pre-generated the keys from my host and 
> for open ssh I still get the "PRNG is not seeded" which I expected but 
> for dropbear it did get as far as accepting the client connection 
> which was the only debug statement I could see on the console.  I 
> captured the SSH packets and could see that it had stalled during the 
> key exchange, I tried using the weakest KexAlgorithm option at the SSH 
> client and still no joy.  It looks as if the dropbear server has 
> failed to reply or has blocked indefinitely.
>
> When generating keys in dropbear I waited for about 15 minutes which 
> from the sounds of it should be long enough to generate a DSS key 
> which I think should be faster to generate than RSA. Besides a 
> Hardware FPU we have all the other instruction set options set.  Do 
> you think the Hardware FPU would make any difference to the 
> encryption?  I would have thought it would have been a lot of integer 
> based number crunching, I maybe wrong here.
>
> Time for some debugging I feel.
>
> Cheers,
> Martin.
>
> On 13/12/13 03:37, Nathan Rossi wrote:
>>> -----Original Message-----
>>> From: meta-xilinx-bounces at yoctoproject.org [mailto:meta-xilinx-
>>> bounces at yoctoproject.org] On Behalf Of Martin Townsend
>>> Sent: Friday, December 13, 2013 2:40 AM
>>> To: meta-xilinx at yoctoproject.org
>>> Subject: [meta-xilinx] SSH Help
>>>
>>> Hi,
>>>
>>> I'm trying to get SSH working and have tried dropbear and openssh with
>>> no joy.  With dropbear it just hangs forever when trying to generate 
>>> the
>>> keys and with openssh I get the following message when trying to
>>> generate the keys
>>> PRNG is not seeded
>>> I've stepped through the code and in seed_rng it calls RAND_Status 
>>> which
>>> I think is in the openssl library.  This function returns failure.
>>> A bit of googling seems to indicate that permissions on /dev/urandom 
>>> and
>>> /dev/random are incorrect but I've checked them and they are fine.
>>>
>>> crw-rw-rw-    1 root     root        1,   8 Jan  1  1970 random
>>> ...
>>> crw-rw-rw-    1 root     root        1,   9 Jan  1  1970 urandom
>>>
>>> Running
>>>
>>> |cat /dev/urandom | tr -dc 'a-zA-Z0-9~!@#$%^&*-_'
>>> gives me a long stream of random characters.
>>>> ZtAy6lC.;yZD3=etLvwbiPEeH_\laccLVXkYlrNa7SiXESYxrb44q*79&I...
>>> |
>>>
>>> Using /dev/random I managed to read 3 characters before it blocked.
>>> cat /dev/random | tr -dc 'a-zA-Z0-9~!@#$%^&*-_'
>>> xAr
>>>
>>> Could it be that the entropy pool isn't being filled enough, the
>>> documentation I can see says that openssl will use /dev/urandom first
>>> and then /dev/random.
>> Hi Martin,
>>
>> I gave openssh/dropbear a quick test on hardware and qemu. The 
>> RSA/ECDSA/DSA host key generation is slow, especially on hardware. It 
>> seems to be related primarily to performance.
>>
>> The qemu system was able to generate the openssh keys in under 1 
>> minute, hardware is 10x slower at ~10 minutes for the kc705-trd 
>> design. Dropbear is much faster, on the kc705 reference design it 
>> will generate the host key within ~10 seconds.
>>
>> As to why QEMU is much faster, it is because it can emulate faster 
>> than hardware runs and it also has all the microblaze instruction set 
>> options enabled (e.g. mul high, hardware div and hard float are the 
>> key options that will affect key generation), remember these keys are 
>> supposed to be computationally hard to generate ;).
>>
>> Alternatively you can skip the host key generation entirely and 
>> pre-generate your host key for debugging (make a recipe to drop it 
>> into your rootfs) and then on you production image configure it to 
>> generate on the first boot and then store the resulting key in a 
>> persistent storage media like flash or sd (which is the default 
>> behavior for poky).
>>
>> Regards,
>> Nathan
>>
>>> BTW: The HW design is using a Microblaze running at 100MHz which I 
>>> would
>>> hope would be enough if maybe a bit slow.
>>>
>>> Any help/ideas greatly appreciated.
>>>
>>> Cheers,
>>> Martin.
>>>
>>> _______________________________________________
>>> meta-xilinx mailing list
>>> meta-xilinx at yoctoproject.org
>>> https://lists.yoctoproject.org/listinfo/meta-xilinx
>>
>
> _______________________________________________
> meta-xilinx mailing list
> meta-xilinx at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-xilinx