0

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 pi@study.local
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.

7
  • The definitive test of whether it's enabled is find /etc/systemd/system -name ssh.service. If that's there, it is. Which doesn't quite guarantee it is run, but it does mean if it doesn't there will be a mess about it in the logs.
    – goldilocks
    Nov 10 '20 at 14:23
  • Bit hard to tell as I cannot ssh in :-). I've no keyboard / monitor free that will fit on a Pi to look at it either so I'll stuck with a re-image on it and see if it starts second time around. If its OK then I will just delete this question else I'll hunt up bits and get it plugged in so I can see.
    – user115418
    Nov 10 '20 at 15:38
  • Closest I have is sshd.service but I cannot find the target (its only an alias) - to add to my troubles my Mac just had a black screen panic and my AV is now being reported as legacy on reboot. Today is not my day! Think I'll call today quits and go paint a figure or two for my son.
    – user115418
    Nov 10 '20 at 16:07
  • Okay got a hypothesis for you...
    – goldilocks
    Nov 10 '20 at 16:35
  • The real Question is WHY would you want to install a new version. I run Raspberry Pi reference 2019-06-20 which I keep updated. I only perform a new install if I want a clean image for testing.
    – Milliways
    Nov 11 '20 at 2:35
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".1 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.

1
  • Apologies - on the Mac they show up as alias file types and I was looking at the files with the Mac before the panic killed everything :-(. I've had to reformat the machine as it was supposed to be set up for lunchtime but I'll see if I have another Pi around to try once I have a keyboard / mouse and screen handy.
    – user115418
    Nov 10 '20 at 18:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy