2

I’m using Debian 11 on a Raspberry Pi 4 (image found here). sshd is properly configured (I only edited /etc/ssh/sshd_config, the rest is completely fresh from system installation) and works correctly when I start it manually. However it doesn’t start automatically by systemd at boot. sudo systemctl status sshd returns this:

● ssh.service - OpenBSD Secure Shell server
     Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: enabled)
     Active: inactive (dead)
       Docs: man:sshd(8)
             man:sshd_config(5)

There is nothing related to ssh in journalctl’s output.

This is the content of /lib/systemd/system/ssh.service:

[Unit]
Description=OpenBSD Secure Shell server
Documentation=man:sshd(8) man:sshd_config(5)
After=network.target auditd.service
ConditionPathExists=!/etc/ssh/sshd_not_to_be_run

[Service]
EnvironmentFile=-/etc/default/ssh
ExecStartPre=/usr/sbin/sshd -t
ExecStart=/usr/sbin/sshd -D $SSHD_OPTS
ExecReload=/usr/sbin/sshd -t
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
Restart=on-failure
RestartPreventExitStatus=255
Type=notify
RuntimeDirectory=sshd
RuntimeDirectoryMode=0755

[Install]
WantedBy=multi-user.target
Alias=sshd.service

The file sshd_not_to_be_run does not exist. network.target is active. I also installed auditd just for troubleshoot and it successfully starts automatically, but ssh.service is still dead after reboot.

I run out of ideas…

UPDATE:

I just discovered that a sshd process spawns on every connection demand. It is managed by systemd itself and it’s clearly printed in the journal when some foreign computers try to connect to mine:

oct. 30 13:09:30 RaspServeur systemd[1]: Started OpenBSD Secure Shell server per-connection daemon (117.68.2.55:45784).
░░ Subject: L'unité (unit) [email protected]:22-117.68.2.55:45784.service a terminé son démarrage
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░ 
░░ L'unité (unit) [email protected]:22-117.68.2.55:45784.service a terminé son démarrage, avec le résultat done.
oct. 30 13:09:30 RaspServeur audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj==unconfined msg='[email protected]:22-117.68.2.55:45784 comm="systemd" exe="/usr/lib/systemd/systemd" ho>
oct. 30 13:09:33 RaspServeur sshd[1861]: error: kex_exchange_identification: Connection closed by remote host
oct. 30 13:09:33 RaspServeur sshd[1861]: Connection closed by 117.68.2.55 port 45784
oct. 30 13:09:33 RaspServeur systemd[1]: [email protected]:22-117.68.2.55:45784.service: Succeeded.
░░ Subject: Unit succeeded
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░ 
░░ The unit [email protected]:22-117.68.2.55:45784.service has successfully entered the 'dead' state.
oct. 30 13:09:33 RaspServeur audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj==unconfined msg='[email protected]:22-117.68.2.55:45784 comm="systemd" exe="/usr/lib/systemd/systemd" hos>

It’s like a parallel installation of sshd exists with a default configuration. My own configuration with settings like a specific port number to use can’t work without starting manually the sshd.service. But I can successfully connect to that shadow sshd with default port, and systemctl status sshd still reports a dead service…

The situation becomes creepy, I’m now two fingers away to erase the SD card and install an image of another distribution with less pre-configuration.

Improve this question
2

2 Answers 2

Reset to default
5

Could this be the same issue as the one the asker of question #442181 had? I.e. sshd fails to start at boot because the interface/address it wants to bind to isn't ready yet. You mention that you've specified a non-standard port for the server socket, have you also specified a particular network interface and/or IP address?

I don't know why systemd instead starts a per-connection daemon that uses the standard configuration, though. It might be part of the default system configuration, as you suggest. In question #507705 they talk about systemd "socket activation", which apparently is the feature that provides per-connection service spawning. Look for a systemd unit file named ssh.socket. You can use man systemd.socket to get information about how the feature works.

Edit: You should be able to use systemctl status ssh.socket to check whether systemd's SSH server socket is enabled.

Improve this answer
2
  • 1
    Indeed, there is a ssh.socket unit implemented, with a line Conflicts=ssh.service inside the definition file. So I disabled this unit, rebooted, then my sshd.service started automatically as expected. Thanks for pointing me to the culprit.
    – Bogey Jammer
    Commented Nov 2, 2021 at 17:58
  • Too bad that the systemctl status ssh* returns only the ssh.service unit, not ssh.socket… Instead I would have discovered it and diagnosed the issue much earlier.
    – Bogey Jammer
    Commented Nov 2, 2021 at 18:04
0

If you start sshd manually, systemd will not register that as started, so it makes sense that systemctl shows nothing. Each sshd really is a listening process and after a connection has been made, a separate process dealing with this connection is forked. If you ps there will be multiple sshd processes reflecting this. Ff you kill the sshd-listener, the other sshd processes that are handling connections will still be alive.

If you start sshd and do a systemctl start sshd. That's the equivalent of starting 2 sshds, which can block if they all try to use the same port.

Hope that helps

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .