SSH turned off after first reboot?

Question

I've just put the 20/8/2020 version of Buster (Raspberry Pi OS (32-bit) with desktop) onto a WD Pi-Drive with a Pi 3B+ hanging off. I added the ssh file to /boot and powered up fine.

I ran terminus from my iPad and and set up (using sudo raspi-config):

• UK Locale (wanted to set Mac keyboard but no options given on keyboard layout)
• GB for the WiFi country code (though I'm connected via Ethernet)
• New system name
• Set the disk to expand at the next boot
• Set start up mode to be command line with no automatic log-on
• Set default video mode to 35 if I need VNC (will issue starts from command line if GUI needed)

I then came out of raspi-config and let the Pi reboot. After waiting about 10 mins (i.e. made a cup of tea) I tried to ssh from my Mac but the connection is refused:

ssh -v [email protected]
OpenSSH_8.1p1, LibreSSL 2.7.3
debug1: Reading configuration data /Users/andrew/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 47: Applying options for *
debug1: Connecting to study.local port 22.
ssh: connect to host study.local port 22: Connection refused

It seems that the ssh ability has been revoked post reboot despite me not disabling the ability in raspi-config.

The file /Users/andrew/.ssh/config has nothing pertaining to this machine name The only active contents of the /etc/ssh/ssh_config file are:

Host *
     SendEnv LANG LC_*

All other lines are comments of blanks.

I checked the file downloaded correctly (sha-256 matched fine) and used Etcher with 'verify on' to cut the image so I'm confident that's not the issue. I also am 100% sure I did not disable ssh when configuring it.

Has anyone else seen this or is this a new 'feature' of the 20/08 version? I have not used the August version before now but not seen this issue on the Feb or May versions.

Later this afternoon I'll redo the disk to see if I can reproduce.

Answer 1

I have is sshd.service but I cannot find the target (its only an alias)

The proper term is a symlink ;) They are used by systemd to enable services (which means you can customize all that without ever running the system, by creating the correct symlinks in the root fs); the various directories contain symlinks to the service files for that general target (eg. "multi-user", "graphical"). You don't need to look at them beyond that. Bit odd it is called sshd.service as on my buster it is ssh.service, but they are the same thing.

Anyway, if it is in /etc/systemd/system (or /lib/systemd/system) it's enabled but it will be for a specific target, namely the one that was the default when it was enabled. For headless/lite, the default target is "multi-user.target", for full desktop version it is "graphical.target".¹ If that's never been changed, only one or the other will be in /etc/systemd/system.

However, if you installed the full GUI version to the card and then ssh'd in, ran raspi-config, and changed the boot option to "console only" (or whatever it is, ie., disable the GUI at boot), then the target probably changed, and ssh might not have been enabled there.

You could confirm that by checking what the /etc/systemd/system/default.target symlink points to. It will be a directory in the same place, either multi-user.target or graphical.target. If it isn't there, check for /lib/systemd/system/default.target.

Point being: One explanation would be if ssh is enabled for multi-user but not graphical (or vice versa) and the default target was changed by changing the boot options with raspi-config.

---

1. Actually that might not be true -- Raspbian appears to use graphical.target for both images for some strange reason (it could be Debian upstream does too).

   Which the reason might be exactly this, so that services can be enabled by high level tools like raspi-config without the risk of mix-up if the default target changes -- although I think the canonical way to do that is to use an /etc/systemd/system/default.target.wants directory.