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

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


  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.