[meta-xilinx] SSH Help

[Martin Townsend]

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
>