I just saw this:
http://www.theregister.co.uk/2015/12/02/raspberry_pi_weak_ssh_keys/
I think that /dev/hwrng support has been in the image for a while now,
but I'm bit out-of-touch of where the latest code is.
Can somebody either verify the BeagleBone's code is correct (for ssh
host key creation) or point me to the repo and I'll take a look?
Josh
So going back to our old 3.8 kernel:
CONFIG_HW_RANDOM_OMAP=m
With the way we create images, the first ssh key is removed: (initial
debootstrap ssh key)
if [ -d "${tempdir}/etc/ssh/" -a "x${keep_ssh_keys}" = "x" ] ; then
#Remove pre-generated ssh keys, these will be regenerated on first bootup...
sudo rm -rf "${tempdir}"/etc/ssh/ssh_host_* || true
sudo touch "${tempdir}/etc/ssh/ssh.regenerate" || true
fi
https://github.com/RobertCNelson/omap-image-builder/blob/master/scripts/chroot.sh#L1146-L1151
Then the init script will generate a new key on bootup:
#Regenerate ssh host keys
if [ -f /etc/ssh/ssh.regenerate ] ; then
rm -rf /etc/ssh/ssh_host_* || true
dpkg-reconfigure openssh-server
sync
if [ -s /etc/ssh/ssh_host_ecdsa_key.pub ] ; then
rm -f /etc/ssh/ssh.regenerate || true
sync
fi
if [ -f /etc/init.d/ssh ] ; then
/etc/init.d/ssh restart
fi
fi
and the flasher makes sure the eMMC will have different keys, then
your boot microSD:
if [ -d /tmp/rootfs/etc/ssh/ ] ; then
#ssh keys will now get regenerated on the next bootup
touch /tmp/rootfs/etc/ssh/ssh.regenerate
flush_cache
fi
Now... if we had a battery backed rtc, it would be better.. But i
think we are in pretty good shape..
So ignoring the root login over 22 with no password... or
nodejs/bonescript/etc.. At least the key is safe. 
Regards,
#Regenerate ssh host keys
if [ -f /etc/ssh/ssh.regenerate ] ; then
rm -rf /etc/ssh/ssh_host_* || true
dpkg-reconfigure openssh-server
sync
if [ -s /etc/ssh/ssh_host_ecdsa_key.pub ] ; then
rm -f /etc/ssh/ssh.regenerate || true
sync
fi
if [ -f /etc/init.d/ssh ] ; then
/etc/init.d/ssh restart
fi
fi
So, it's a bit late, and I'm a bit grogy but I think this is where the
issue might be. It's not good enough just to call regenerate if the
entropy pool isn't properly seeded, otherwise the key generated will be
predictable.
And while the hwrng is enable I don't think it actively contributes to
the kernel entropy pool. I *thought* that is where there is the user
space rngd daemon, but again... tired...
The issue is the creation of /var/lib/systemd/random-seed, which
could/should be done by dd'ing from /dev/hwrng to this file. If software
creates this, then it will be predictable.
So ignoring the root login over 22 with no password... or
nodejs/bonescript/etc.. At least the key is safe.
touche, we are plugging a leak while water is pouring over our heads 
I still advocate removing the the no password root login thing.
#Regenerate ssh host keys
if [ -f /etc/ssh/ssh.regenerate ] ; then
rm -rf /etc/ssh/ssh_host_* || true
dpkg-reconfigure openssh-server
sync
if [ -s /etc/ssh/ssh_host_ecdsa_key.pub ] ; then
rm -f /etc/ssh/ssh.regenerate || true
sync
fi
if [ -f /etc/init.d/ssh ] ; then
/etc/init.d/ssh restart
fi
fiSo, it's a bit late, and I'm a bit grogy but I think this is where the
issue might be. It's not good enough just to call regenerate if the
entropy pool isn't properly seeded, otherwise the key generated will be
predictable.And while the hwrng is enable I don't think it actively contributes to
the kernel entropy pool. I *thought* that is where there is the user
space rngd daemon, but again... tired...The issue is the creation of /var/lib/systemd/random-seed, which
could/should be done by dd'ing from /dev/hwrng to this file. If software
creates this, then it will be predictable.
and i'm not an expert either, so with 4.1.13-ti-r34:
debian@test-bbb-3:~$ uname -r
4.1.13-ti-r34
debian@test-bbb-3:~$ journalctl | grep entropy
Dec 02 04:15:42 test-bbb-3 kernel: random: systemd-udevd urandom read
with 10 bits of entropy available
That's before the init script runs...
So ignoring the root login over 22 with no password... or
nodejs/bonescript/etc.. At least the key is safe.touche, we are plugging a leak while water is pouring over our heads
I still advocate removing the the no password root login thing.
Regards,
Ok, my conclusion is that we have the same problem then as the RPi which
is the state of the RNG is "poor" prior to generating ssh keys.
Pull request, with links to various references, is here:
https://github.com/RobertCNelson/omap-image-builder/pull/65
I ran the dd command (with sudo) on a BBB and verified that yes, reading
from the HWRNG does work (wasn't that surprised...) but I didn't try
running that script / repo on a BBB.
Josh
