Autossh wraps SSH in an application which was designed to monitor the state of the connection. It will also restart SSH if it exits. The idea of the monitoring is that If it sees the packets aren’t going through, it would also restart SSH. …
the developers of OpenSSH added some options – ServerAliveInterval and ServerAliveCountMax – which activate built in connection checking in OpenSSH. Together the options set checking at a set interval and exiting SSH if the count maximum is exceeded. And when SSH exits, autossh will restart it so it serves as much improved replacement as there’s no extra ports needed.
Summary
The scenario is that a client user named autoSshClientUser automatically logs on to a server as user autosshServerUser using autossh from the client system.
The sequence is to first test this manually from the client system using a regular ssh command, then manually with the autossh command from the client system, then automate the starting (and keep alive) of the autossh instance from the client system.
Start configuring the server side first:
Create a user specific for logon (below it is autosshServerUser).
As root use su to become autosshServerUser, then create an ssh key without a password (you need to specify the logon shell) using [WayBack] ssh-keygen.
This generates bot a secure rsa and
# su --shell /bin/bash autosshServerUser
> cd ~
> whoami
autosshServerUser
> rm -f ~/.ssh/id_rsa ~/.ssh/id_rsa.pub
> ssh-keygen -t rsa -b 4096 -o -a 100 -f ~/.ssh/id_rsa -N ''
Generating public/private rsa key pair.
Your identification has been saved in /home/autosshServerUser/.ssh/id_rsa.
Your public key has been saved in /home/autosshServerUser/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:... autossh24@linux
The key's randomart image is:
+---[RSA 2048]----+
...
+----[SHA256]-----+
> rm -f ~/.ssh/id_ed25519 ~/.ssh/id_ed25519.pub
> ssh-keygen -t ed25519 -o -a 100 -f ~/.ssh/id_ed25519 -N ''
Generating public/private ed25519 key pair.
Your identification has been saved in /home/autossh24/.ssh/id_ed25519.
Your public key has been saved in /home/autossh24/.ssh/id_ed25519.pub.
The key fingerprint is:
SHA256:... autossh24@linux
The key's randomart image is:
+--[ED25519 256]--+
...
+----[SHA256]-----+
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
Create a template service file at /etc/systemd/system/secure-tunnel@.service. The template parameter will correspond to the name
of target host:
[Unit]Description=Setup a secure tunnel to %I
After=network.target
[Service]Environment="LOCAL_ADDR=localhost"EnvironmentFile=/etc/default/secure-tunnel@%i
ExecStart=/usr/bin/ssh -NT -o ServerAliveInterval=60 -o ExitOnForwardFailure=yes -L ${LOCAL_ADDR}:${LOCAL_PORT}:localhost:${REMOTE_PORT} ${TARGET}
# Restart every >2 seconds to avoid StartLimitInterval failureRestartSec=5
Restart=always
[Install]WantedBy=multi-user.target
We need a configuration file (inside /etc/default) for each target host we will be creating tunnels for. For example, let’s assume we want to tunnel to a host named jupiter (probably aliased in /etc/hosts). Create the file at /etc/default/secure-tunnel@jupiter:
Note that for the above to work we need to have allready setup a password-less SSH login to target (e.g. by giving access to a non-protected private key).
Now we can start the service instance:
systemctl start secure-tunnel@jupiter.service
systemctl status secure-tunnel@jupiter.service
Leave a comment