FIX:- PRNG is not seeded

By: Published: Oct 22nd, 2012 Category: Linux Tips

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
 FIX:  PRNG is not seeded

About 

Milind Koyande is a Project Manager and his job is to work with new technologies, specially Cloud Computing / Virtualization Technology. His past projects include Government Sector initiatives, Backup and Disaster Recovery Solutions.

Tags: , , , , , ,

5 Responses to “FIX:- PRNG is not seeded”


  1. Qmail says “PRNG not seeded” when sending mail to certain servers
    on Nov 26th, 2010
    @ 5:24 pm

    […] http://eitwebguru.com/fix-prng-is-not-seeded/ June 27, 2010 3:39 am Eric3 Both devices already existed, but by deleting and then re-adding them the problem went away. June 30, 2010 2:52 am David Spillett As well as making sure that the relevant devices exist (as per David Smith’s answer) you need to make sure there is actually some entropy in the pool. […]


  2. marcelo
    on Jan 26th, 2011
    @ 2:44 am

    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?


  3. marcelo
    on Jan 26th, 2011
    @ 3:27 am

    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 ;)


  4. Milind
    on Jan 29th, 2011
    @ 8:46 am

    Thanks for the fix Marcelo :)


  5. Sean
    on Dec 15th, 2012
    @ 2:20 am

    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.

Leave a Reply

Subscribe to eITWebguru

© 2012 eITWebguru. All Rights Reserved.