@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 ;)
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 🤔
I should've known systemd had taken over that too 😂
@FreePietje When systemd-bitcoind?
The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!