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

About 

Milind Koyande loves to work on new technologies specially virtualization and troubleshoot server problems. I’m an avid photographer and love to spend my free time close to nature, trying to capture its glory on my camera.

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.