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
Milind Koyande is the Senior Research Engineer 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.
Milind Koyande is the Senior Research Engineer 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. Follow him on 
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. [...]
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?
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 ;)
Milind
on Jan 29th, 2011
@ 8:46 am:
Thanks for the fix Marcelo :)
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.