systemd socket activation to create a permanent SSH tunnel

[Damien Miller]

On Sat, 28 Mar 2026, R. Diez via openssh-unix-dev wrote:

> Hi all:
> 
> I have configured an SSH tunnel in ~/.ssh/config with "ssh -N",
> "LocalForward", "ControlPersist", etc. The trouble is, I have to start it
> manually every day.
> 
> I have looked at autossh, but the trouble is, if the network is down, or the
> remote server changes credentials, autossh will forever keep trying to open
> the SSH tunnel, polluting the failure log. The same would happen with a
> systemd service set to automatically restart, it will keep failing and
> triggering failed service alerts in Prometheus.
> 
> The right thing to do would be to set up a systemd socket activation for the
> SSH tunnel. This way, when an application tries to connect to the local tunnel
> endpoint, systemd will automatically start the SSH tunnel command. If nobody
> is trying to use the tunnel, then the system will not attempt to establish the
> connection.
> 
> The trouble is, systemd passes the socket file descriptor to the child process
> in environment variable LISTEN_FDS. The reason is, the child process cannot
> open the socket for listening purposes, because systemd's socket activation
> has already done it.
> 
> I gather that opensshd (the daemon) supports the LISTEN_FDS mechanism, because
> I have read somewhere that this is the way many Linux distributions start
> OpenSSH, even before systemd existed.

I don't know if Linux distributions are using socket activation to start
sshd. I posted a WIP patch to support this [1] some time ago but never got
any feedback on it.

[1] https://github.com/djmdjm/openssh-portable-wip/pull/7

> Does "ssh" (the SSH client) support LISTEN_FDS too? I could not find any
> mention of LISTEN_FDS in its documentation.

No - ssh doesn't support LISTEN_FDS; ssh isn't a daemon and IMO it
doesn't make much sense to activate it as one. Each invocation of
ssh generally needs to be uniquely configured, unlike a daemon that
typically has a single configuration.

> I need socket activation support in "ssh", because socket activation should
> trigger the ssh command to establish the tunnel, and that does not involve the
> SSH daemon on the local PC, only the ssh client (as far as I understand it).

I think you need _something_ that supports socket activation, and then
starts a ssh process with your preferred destination/configuration and
then plumbs the waiting socket to it after it has successfully
authenticated.

I'd suggest prototyping this in Go or python.

-d