For the time being, let's keep both Pi 3/Pi 4 and Pi 5 recipes separate,
making it easy to modify the latter freely. Later on, it will probably
make sense to have a common section.
Let's *disable* ssh.service to make sure it doesn't start too soon, and
modify the rpi-generate-ssh-host-keys.service unit (that triggers the
generation during the first boot) to enable+start ssh.service when
everything is ready.
See: https://salsa.debian.org/raspi-team/image-specs/-/issues/72
The original image leads to repeated failures to start for sshd.service
since there are no host keys initially. Make sure the unit in charge of
getting those keys generated runs before sshd.
The following block gets repeated otherwise:
systemd[1]: Starting ssh.service - OpenBSD Secure Shell server...
sshd[795]: sshd: no hostkeys available -- exiting.
systemd[1]: ssh.service: Control process exited, code=exited, status=1/FAILURE
systemd[1]: ssh.service: Failed with result 'exit-code'.
systemd[1]: Failed to start ssh.service - OpenBSD Secure Shell server.
systemd[1]: ssh.service: Scheduled restart job, restart counter is at 1.
systemd[1]: Stopped ssh.service - OpenBSD Secure Shell server.
It's a matter of habit more than an absolute technical requirement.
Quoting the useradd manpage:
useradd is a low level utility for adding users. On Debian,
administrators should usually use adduser(8) instead.
The default SSH configuration is Debian 12 is as follows:
#PermitRootLogin prohibit-password
#PermitEmptyPasswords no
(The default values are commented out, ready to be tweaked by local
admins.)
It's pretty standard to have 127.0.0.1 match localhost while the actual
machine's name (FQDN and hostname) matches 127.0.1.1 instead.
We would be happy to be told if something similar exists for IPv6!
