Friends don't let friends generate insecure keys. Headless raspi setups generate ssh keys on first boot with relatively little entropy.
Don't forget to `dd if=/dev/random of=$raspi_root_mountpoint/var/lib/systemd/random-seed bs=1 count=512` before the first boot.
Besides 'liking' it, I also want to verbally show my support for this.
I very much like the enthusiasm for all those efforts, but I do feel there's too little attention to these (imo) crucial elements.
You should (also) do:
and then start the rngd daemon from the rng-tools package.
This will massively increase the entropy pool.
You probably want to make it so that that happens at every boot.
@FreePietje will look into that as well, thanks.
@FreePietje The intent is not to do this from inside of the booted raspbian - rather my suggestion is to bootstrap the random-seed file with some decent entropy (*far* better than none), from the OS used to write the raspbian image to the sd or hdd in the first place.
Ok. I got the impression that it was to be run from the RPi itself.
BTW: I got the bcm2835-rng idea from https://github.com/debian-pi/raspbian-ua-netinst/blob/v1.1.x/scripts/etc/init.d/rcS#L234
The project is unfortunately a bit outdated (installs Jessie), but it starts gathering entropy with RPi's HWRNG quite early and then starts a complete installation process, which in itself generates a lot of entropy (afaiui).
You can customize the installation (config file + scripts), including generating keys at the end of the installation.
> Ok. I got the impression that it was to be run from the RPi itself.
No, in my first toot I said *before the first boot*. Hard to do that from within the OS ;)
You mean, download an image, mount it on your 'PC', do the dd to create the seed file, umount it and write it to the SD card?
Now the $raspi_root_mountpoint makes more sense :)
I generally don't like (Raspberry Pi Foundation) images as everyone has the same keys (which you *can* (and should) regenerate) and everything is setup to work properly with the 'pi' user, but things fall apart when you create a new user.
Not using (and actually disabling) 'pi' increases your security.
@FreePietje Which keys does everyone share?
Maybe others, but I haven't used/tried the RPF images in a LONG time (also because it contains a lot of software I'm not interested in)
@FreePietje Hang on, it doesn't just generate SSH keys with low entropy... It has hardcoded keys?
Yep. When you install openssh-server, the host keys get generated and that package gets installed during creation of the(ir) image, thus everyone has the same server keys.
Maybe they've changed things since, but I've had/read several discussions (quite a while ago) where I understood their reasoning, but didn't agree with it. Usable for noobs is a valid reason to make certain choices, just not for me (as I'm not a noob).
That's why I like that netinstaller. My rules and my choices.
@kekcoin Maybe/hopefully they have changed things and regenerate the/those keys on first boot (with low entropy ...).
It would be great if that's the case and my previous statement is wrong.
@FreePietje I do remember checking journalctl and seeing a line about generating ssh keys occurring after the line about loading the random-seed from the filesystem. I'll check right now whether a freshly dd'ed image contains those keys...
@FreePietje (Using raspbian stretch lite from raspberrypi.org)
@FreePietje Interesting. Those keyfiles do not exist before first boot, but they are seemingly generated before any sort of system clock sync as the keyfiles on the installed system (generated in the last 24h) are dated 13 nov 2018. So you don't even get any entropy from system clock.
https://github.com/RPi-Distro/raspi-config/blob/master/raspi-config#L664 indicates that it does indeed generate new keys.
I was wondering where that date came from and found it: https://downloads.raspberrypi.org/raspbian_lite/archive/2019-04-09-22:48/
They probably use fake-hwclock to store the last date and then regenerate those keys before ntp is run (assuming that's installed).
I should probably take a proper look myself sometime.
@FreePietje This is weird, by the way - you linked the "april 2019" release yet it's dated nov 2018.
@FreePietje Or is the date in the archive corresponding to when the files were archived and it actually means the previous version? I am confused.
It is indeed weird and confusing and I don't really understand what RPF has done there. There is a consistent pattern though.
If you look at the files inside the '2018-11-15-21:03' folder, you see timestamps close to the preceding timestamp folder.
So it could be I linked to the wrong folder, but that I was essentially still correct.
There was a /etc/fake-hwclock.data file with a timestamp (but no /etc/ntf.conf file ...)
@FreePietje It certainly seems that they cut the archive of the previous version around the time the next version is released, and then name it with the timestamp at which the archive is made, rather than the name/date of the release.
This means it's unlikely ntp is installed 🤔