Why ssh.service can be disabled while SSH still works

One of the more useful Linux learning moments started with an apparently contradictory observation: ssh.service could be disabled while remote SSH still worked.

That immediately showed that my mental model — “SSH works because the SSH service is enabled and permanently listening” — was incomplete.

Separate the names first

sshd is the SSH server daemon program. ssh.service is a systemd service unit that describes how systemd manages that daemon. ssh.socket is a systemd socket unit that can own the listening socket and activate the associated service when traffic arrives.

Those are related, but they are not three names for the same thing.

What socket activation changes

With traditional always-on service startup, the service starts early and the daemon itself opens the listening socket. With socket activation, systemd can create and hold the listening socket first. The service can then be started when activity on that socket makes it necessary.

This means “is the service enabled?” is not enough evidence to answer “what is accepting connections on this port?”

The evidence I want, not just the explanation

The useful investigation is to prove each layer:

Which unit is enabled or active?
Which process owns the listening socket before a connection?
Does the service state change when a client connects?
What do the systemd logs record at that moment?
What happens to the service after the connection ends?

The last question is especially important because the answer can depend on the unit configuration. I should not assume that socket activation means the daemon always disappears immediately after the session closes; that needs to be verified on the actual system.

The bigger lesson

A service manager introduces another layer between “a program exists” and “a network service is reachable”. Once socket units, dependencies and activation are involved, process state, unit state and socket state are different pieces of evidence.

Diagnostic habit: when a network service behaves differently from what the service status suggests, inspect the listener and the activation path rather than treating the unit name as the whole system.

Next investigation

The follow-up is to compare this with Android/Termux on a battery-powered Samsung S23, where systemd may not be the service manager. That forces the same question in a different environment: what starts the SSH server, what keeps it alive, and is on-demand activation actually useful?