Security bug? Fixed sshd host keys supplied with rootfs

Hello,

I just managed to install Debian on my NSA325v2 thanks to the excellent resources found here
and the nas-central.org wiki.

But this thing caught my eye, after booting into Debian for the first time, it looks like sshd keys are used straight
from the Debian-3.18.5-kirkwood-tld-1-rootfs-bodhi.tar.bz2 tarball and not regenerated? This would mean that all the Debian
installs from this image around the world are running with a compromised ssh config and using a public "private key" meaning ssh communications aren't protected at all! Am I missing something?



Edited 2 time(s). Last edit at 10/17/2015 07:38AM by erno.

Yes, you're missing the fact that @bodhi posted instructions on how you can regenerate those keys. Also he firmly suggests that you should do that on your first run on his rootfs.

Read carefully his guide.

Quote from his topic:

Quote

Note1:

After logging in this rootf the first time, remember to generate new SSH key to make it your own unique rootfs. And also update your rootfs to get the latest Debian package updates:
rm /etc/ssh/ssh_host*
ssh-keygen -A

Edited 1 time(s). Last edit at 10/17/2015 09:10AM by JohnnyUSA.

I see! May I suggest this is still a quite failure-prone ("fail-open") setup, and it would be better to remove those keys from the
supplied tarball. Also, this stil leaves the issue of the random seed. If everyone removes the keys and then
regenerates the ssh keys with urandom primed with same seed, it's not good even though there is a little bit of runtime randomness mixed in.

http://security.stackexchange.com/questions/2943/what-are-the-chances-to-generate-the-same-ssh-key

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

That's indeed a good treatment of the issue, with the first answer discussing how things work out with good randomness and the last answer discussing what happens with bad randomness!