Random device has blocked - SSH

This is a discussion on Random device has blocked - SSH ; I've got a system with very low activity (basically, it runs only about 10 processes; mostly ssh and rsync.) Aftter it boots up, I cannot log in via ssh because the random device has blocked.... There doesn't seem to be ...

+ Reply to Thread
Results 1 to 8 of 8

Thread: Random device has blocked

  1. Random device has blocked

    I've got a system with very low activity (basically, it runs only about 10
    processes; mostly ssh and rsync.)

    Aftter it boots up, I cannot log in via ssh because the random device has
    blocked....

    There doesn't seem to be much pattern in this; sometimes I can just loop
    cat xxx; sleep 1 for a while and it unblocks. Other times I have to wait
    for several hours to be able to log in, and even running rsync on a 2 GB
    filesystem apparently doesn't generate enough entropy....

    What can I do to generate sufficient entropy in the system?

    Thanks,

    --Yan



  2. Re: Random device has blocked

    Captain Dondo writes:

    >I've got a system with very low activity (basically, it runs only about 10
    >processes; mostly ssh and rsync.)


    >Aftter it boots up, I cannot log in via ssh because the random device has
    >blocked....


    Idiots. It sounds like ssh is using /dev/random rather than /dev/urandom,
    which is idiotic. They should be using /dev/urandom. This is the openssh
    writers playing silly buggers with their software. They read the man pages
    and decided that /dev/random sounded more secure, and forgot completely
    about its blocking.\

    Move the mouse around a lot, have lots of disk activity. These are places
    that /dev/random looks for randomness.

    Also, here is the advice from man urandom ( which is also man 4 random, but
    if you just do man random you get the very weak "random" function call
    which has absolutely nothing to do with /dev/random)

    When a Linux system starts up without much operator interaction, the
    entropy pool may be in a fairly predictable state. This reduces the
    actual amount of noise in the entropy pool below the estimate. In
    order to counteract this effect, it helps to carry entropy pool infor-
    mation across shut-downs and start-ups. To do this, add the following
    lines to an appropriate script which is run during the Linux system
    start-up sequence:

    echo "Initializing kernel random number generator..."
    # Initialize kernel random number generator with random seed
    # from last shut-down (or start-up) to this start-up. Load and
    # then save 512 bytes, which is the size of the entropy pool.
    if [ -f /var/random-seed ]; then
    cat /var/random-seed >/dev/urandom
    fi
    dd if=/dev/urandom of=/var/random-seed count=1

    Also, add the following lines in an appropriate script which is
    run
    during the Linux system shutdown:

    # Carry a random seed from shut-down to start-up for the random
    # number generator. Save 512 bytes, which is the size of the
    # random number generator's entropy pool.
    echo "Saving random seed..."
    dd if=/dev/urandom of=/var/random-seed count=1

    >There doesn't seem to be much pattern in this; sometimes I can just loop
    >cat xxx; sleep 1 for a while and it unblocks. Other times I have to wait
    >for several hours to be able to log in, and even running rsync on a 2 GB
    >filesystem apparently doesn't generate enough entropy....


    >What can I do to generate sufficient entropy in the system?


    >Thanks,


    >--Yan




  3. Re: Random device has blocked

    > I've got a system with very low activity (basically, it runs only about 10
    > processes; mostly ssh and rsync.)
    >
    > Aftter it boots up, I cannot log in via ssh because the random device has
    > blocked....
    >
    > There doesn't seem to be much pattern in this; sometimes I can just loop
    > cat xxx; sleep 1 for a while and it unblocks. Other times I have to wait
    > for several hours to be able to log in, and even running rsync on a 2 GB
    > filesystem apparently doesn't generate enough entropy....
    >
    > What can I do to generate sufficient entropy in the system?


    Pay someone to sit at the console and type. : )

    You could change the /proc/sys/kernel/random/poolsize file to gather a
    larger pool of entropy when the machine *is* active, or you can try to
    create more entropy in the first place.

    In order to create more entropy, you can cause activity which will allow
    the kernel to gather entropy, which (if I recall) includes interrupts,
    jitter in network packets, hard disk activity, key presses, and various
    other things.

    There are also other sources of entropy, such as the hardware PRNG in
    various motherboard chipsets today. There are also other sources - if I
    recall, a fellow wrote a PRNG that used the thermal noise from a cheap
    webcam with the lens covered up - and if I recall correctly, it did a very
    fine job.

    You can have a random seed saved for /dev/urandom, but SSH reads from
    /dev/random, so that doesn't help a whole lot.

    From your message, it sounds like the problem may only occur after boot,
    which is a little odd, because the boot process usually involves a good
    amount of disk activity - which would build up the pool very quickly.
    Perhaps you could tell us more about the system in question.

    steve




  4. Re: Random device has blocked

    Steve Wolfe wrote:

    > From your message, it sounds like the problem may only occur after boot,
    > which is a little odd, because the boot process usually involves a good
    > amount of disk activity - which would build up the pool very quickly.
    > Perhaps you could tell us more about the system in question.


    The system is an old mac, running busybox. Thus there is very little
    activity - all it really does is get an IP, run dropbear (a ssh server)
    and that's it. The whole bootup takes just a few seconds...

    ANd because there really are no daemons running, and noone is at the
    keyboard, there is very little activity.

    Thus I am looking for some little program that I can run - something
    that will run with little CPU power but generate lots of entropy. If I
    can run this for say 10 minutes after I boot up, it might work.

  5. Re: Random device has blocked

    "Steve Wolfe" writes:

    >> I've got a system with very low activity (basically, it runs only about 10
    >> processes; mostly ssh and rsync.)
    >>
    >> Aftter it boots up, I cannot log in via ssh because the random device has
    >> blocked....
    >>
    >> There doesn't seem to be much pattern in this; sometimes I can just loop
    >> cat xxx; sleep 1 for a while and it unblocks. Other times I have to wait
    >> for several hours to be able to log in, and even running rsync on a 2 GB
    >> filesystem apparently doesn't generate enough entropy....
    >>
    >> What can I do to generate sufficient entropy in the system?


    > Pay someone to sit at the console and type. : )


    > You could change the /proc/sys/kernel/random/poolsize file to gather a
    >larger pool of entropy when the machine *is* active, or you can try to
    >create more entropy in the first place.


    > In order to create more entropy, you can cause activity which will allow
    >the kernel to gather entropy, which (if I recall) includes interrupts,
    >jitter in network packets, hard disk activity, key presses, and various
    >other things.


    > There are also other sources of entropy, such as the hardware PRNG in
    >various motherboard chipsets today. There are also other sources - if I
    >recall, a fellow wrote a PRNG that used the thermal noise from a cheap
    >webcam with the lens covered up - and if I recall correctly, it did a very
    >fine job.


    > You can have a random seed saved for /dev/urandom, but SSH reads from
    >/dev/random, so that doesn't help a whole lot.


    It is stupid for ssh to read from /dev/random. You can get precisely the
    blocking behaviour seen. And /dev/urandom also reads the entropy pool and
    uses that if possible. Only if not enough is available does it stretch it
    out with a high quality random stream generator.

    They should at least have a config parameter allowing you to choose urandom
    over random.

    Note that the danger from /dev/urandom being broken to the safety of ssh is
    lower than the probability that you will be killed by a meteorite as you
    enter the password. It is idiocy to try to protect against urandom being
    broken in the face of all of the far far more probably ways of being broken
    into. And by leading to such blocking behaviour it encourages people not
    to use ssh at all (eg going back to telnet).







    > From your message, it sounds like the problem may only occur after boot,
    >which is a little odd, because the boot process usually involves a good
    >amount of disk activity - which would build up the pool very quickly.
    >Perhaps you could tell us more about the system in question.






  6. Re: Random device has blocked

    CptDondo writes:

    >Steve Wolfe wrote:


    >> From your message, it sounds like the problem may only occur after boot,
    >> which is a little odd, because the boot process usually involves a good
    >> amount of disk activity - which would build up the pool very quickly.
    >> Perhaps you could tell us more about the system in question.


    >The system is an old mac, running busybox. Thus there is very little
    >activity - all it really does is get an IP, run dropbear (a ssh server)
    >and that's it. The whole bootup takes just a few seconds...


    Ah. Whatever dropbear is it is an old badly written program. On a modern
    Linux, openssh used openssl to give the randomness if possible. And openssl
    has the lines

    #ifdef DEVRANDOM
    memset(randomstats,0,sizeof(randomstats));
    /* Use a random entropy pool device. Linux, FreeBSD and OpenBSD
    * have this. Use /dev/urandom if you can as /dev/random may block
    * if it runs out of random entries. */

    Get the sourcecode for dropbear, and replace /dev/random in the source with
    /dev/urandom. Recompile and use that!


    Of course you do not tell us which OS you are running, or whetehr your os
    has /dev/urandom.

    If not, you are in trouble, and you will block.

    YOu could always use /dev/random but test it for blocking. When you have as
    much entropy as you can gather, and if it is not enough feed that into an
    entropy amplification routine. Ie, write your own equivalent to urandom (
    of course best is to just use its routing and T Tso spent a fair amount of
    thought designing urandom. Or find someone elses entropy amplifier. There
    was a huge discussion in sci.crypt about a year ago about /dev/random,
    /dev/urandom and improvements to them.




    >ANd because there really are no daemons running, and noone is at the
    >keyboard, there is very little activity.


    >Thus I am looking for some little program that I can run - something
    >that will run with little CPU power but generate lots of entropy. If I
    >can run this for say 10 minutes after I boot up, it might work.


    Well, you could always copy files. However it might well be that you do not
    have a hard disk, in which case hard disk activity would be limited.


  7. Re: Random device has blocked

    CptDondo writes:

    > Thus I am looking for some little program that I can run - something
    > that will run with little CPU power but generate lots of entropy.
    > If I can run this for say 10 minutes after I boot up, it might work.


    A cron job that runs 'ls -lR 2>&1 > /dev/null' every so often should
    create some interrupts. If you have wget, curl, or lynx installed you
    can also fetch web pages and redirect them to /dev/null to create
    network activity.

    You might also want to look at ssh-rand-helper, which is used on
    systems that don't have /dev/random.

    --
    David Magda
    Because the innovator has for enemies all those who have done well under
    the old conditions, and lukewarm defenders in those who may do well
    under the new. -- Niccolo Machiavelli, _The Prince_, Chapter VI

  8. Re: Random device has blocked

    On 2005-11-01, Unruh wrote:
    > Captain Dondo writes:
    >
    >>I've got a system with very low activity (basically, it runs only about 10
    >>processes; mostly ssh and rsync.)
    >>Aftter it boots up, I cannot log in via ssh because the random device has
    >>blocked....


    Are you sure it's the random device? It sounds like it, but how did you
    determine it for sure?

    > Idiots. It sounds like ssh is using /dev/random rather than /dev/urandom,
    > which is idiotic. They should be using /dev/urandom. This is the openssh
    > writers playing silly buggers with their software. They read the man pages
    > and decided that /dev/random sounded more secure, and forgot completely
    > about its blocking.\


    Perhaps you should read the code to see what OpenSSH actually does before
    criticizing. (Hint: it's not what you assumed above.)

    [and in a later post, after it was mentioned that Steve is using dropbear]
    > It is stupid for ssh to read from /dev/random. You can get precisely the
    > blocking behaviour seen. And /dev/urandom also reads the entropy pool and
    > uses that if possible. Only if not enough is available does it stretch it
    > out with a high quality random stream generator.


    > They should at least have a config parameter allowing you to choose urandom
    > over random.


    Perhaps you should read the code to see what Dropbear actually does before
    criticizing. (Hint: read the comments around DROPBEAR_DEV_URANDOM.)

    To the OP, some suggestions:
    * Check the device special for /dev/urandom and make sure it's the correct
    major and minor (1 & 9 repectively, assuming it's Linux) and that it's
    readable.

    * If you have sound hardware you might like to look at this project, which
    collects entropy by sampling white noise from an audio source and feeding
    it into the pool:
    http://www.vanheusden.com/aed/

    * Saving and restoring the entropy pool over reboots as mentioned upthread
    is also a good idea (providing you have suitable stable storage, you might
    not want to do it on, eg, flash).

    During the last discussion on the topic that I saw, timing of network
    packets was not used an an entropy source by Linux's random device,
    because they are assumed to be under the control of an external party.
    That discussion would be in the lkml archive somewhere.

    --
    Darren Tucker (dtucker at zip.com.au)
    GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
    usually comes from bad judgement.

+ Reply to Thread