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
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?
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 ;)
Thanks for the fix Marcelo :)
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.