Linux Tips

FIX:- PRNG is not seeded

Recently working on a Debian server, which was not responding to SSH connection. I have checked and found that the SSH service was down and while restarting it it gives following error

sh-3.1# /etc/init.d/ssh restart
PRNG is not seeded
sh-3.1#


I have searched on Google and found that the problem occurs when /dev/random and /dev/urandom are missing from the server.

sh-3.1# ls -al /dev/random
/bin/ls: /dev/random: No such file or directory
sh-3.1# ls -al /dev/urandom
/bin/ls: /dev/urandom: No such file or directory


As it was a VPS I directly logged into it from the host server but in case of Dedicated/Physical Server you will have to use console. Once you logged into the server execute following commands to create /dev/random and /dev/urandom

sh-3.1# mknod /dev/random c 1 9
sh-3.1# mknod /dev/urandom c 1 9

4 Comments

  1. marcelo

    Hi there, I had the same exact problem and after trying your solution the PRNG issue has gone, but the sshd service is still down.

    [root /]# etc/init.d/sshd restart
    Stopping sshd:[FAILED]
    Starting sshd:[ OK ]
    [root /]# service sshd status
    sshd dead but subsys locked

    any idea?

  2. marcelo

    I found the solution, may be helpful for others.
    To unlock the issue just run:

    rm -rf /dev/null
    mknod -m 666 /dev/null c 1 3

    then restart sshd and try to login as root. If you obtain a message saying “Server refused to allocate pty”, then run:

    /sbin/MAKEDEV pty
    /sbin/MAKEDEV tty

    and restart sshd. This should do the trick ;)

  3. Milind

    Thanks for the fix Marcelo :)

  4. Sean

    It bears noting that the correct mknod minour device number for /dev/random is actually 8:

    mknod -m 644 /dev/random c 1 8
    mknod -m 644 /dev/urandom c 1 9

    What you’re doing by using 1,9 for /dev/random is eliminating entropy.

    I’m presently tackling an issue with the lack of entropy for a headless embedded system which has no keyboard/mouse/IDE, which are the three devices which the kernel uses as sources of entropy, so we’ve got to rewrite the kernel implementation of /dev/random to utilize a real-world entropy source which our device happens to have access to. In the meantime, FOR TESTING ONLY, I removed /dev/random and recreated it using the major,minour device values for urandom. This results in a totally cryptographically insecure /dev/random, but at least it doesn’t block for near infinity when something comes along seeking rand.

    This can be a useful test:

    time dd if=/dev/random of=/tmp/testfile.rand count=4096 bs=1

    Does in return in < 1 sec, or sit there for MINUTES or even HOURS?

    Headless VMs can be expected to run into similar blocking issues.

This site uses Akismet to reduce spam. Learn how your comment data is processed.