The Wiert Corner – irregular stream of stuff

Jeroen W. Pluimers on .NET, C#, Delphi, databases, and personal interests

  • My badges

  • Twitter Updates

  • My Flickr Stream

  • Pages

  • All categories

  • Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    Join 2,164 other followers

OpenSuSE: keeping an ssh connection alive (convenient for keeping port forwardings up)

Posted by jpluimers on 2020/05/11

Below the steps for ensuring port forwardings are up from an OpenSuSE system to an ssh server using autossh on the client system.


Many have written about the benefits of autossh, so I can’t do better than that. A good abbreviated quote is from [WayBack] Autossh for persistent database connectivity – Compose Articles:

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.


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:

  1. Create a user specific for logon (below it is autosshServerUser).
  2. Limit the user to only allow only port forwarding: [WayBacksecurity – How to create a restricted SSH user for port forwarding? – Ask Ubuntu

Then finish confiruging the client side:

  1. Install autossh: zypper install autossh
  2. Ensure autoSshClientUser has an ssh key that does not require a password
  3. Transfer the public key to autosshServerUser on the remote system
  4. Test with an autossh command that suits your situation best
  5. Ensure autoSshClientUser runs a job at or shortly after system boot (after the network is up) that will start autossh with the correct parameters

If the autoSshClientUser is root, then you could use a service to start autossh, but be sure that service depends on a functioning network connection.

If the autoSshClientUser is not root, then usually a user based cron job works best.

Naming idea:

  • Assume the client system is Train and the server is Station
  • The server user could be autosshTrainAtStation
  • The client user could be autosshTrainToStation

Server side

  1. [] Installing on other OSes (Debian / Ubuntu;  Debian / Ubuntu; CentOS / Fedora / RHEL; ArchLinux; FreeBSD; OSX)
  2. As root, add he user using []useradd:

    # useradd --create-home --shell /bin/false autosshServerUser

  3. As root use su to become autosshServerUser, then create an ssh key without a password (you need to specify the logon shell) using [WayBackssh-keygen.
    This generates bot a secure rsa and

    # su --shell /bin/bash autosshServerUser
    > cd ~
    > whoami
    > rm -f ~/.ssh/id_rsa ~/.ssh/
    > 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/
    The key fingerprint is:
    SHA256:... autossh24@linux
    The key's randomart image is:
    +---[RSA 2048]----+
    > rm -f ~/.ssh/id_ed25519 ~/.ssh/
    > 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/
    The key fingerprint is:
    SHA256:... autossh24@linux
    The key's randomart image is:
    +--[ED25519 256]--+

Client side

I need to check the below links on killing autossh (including the underlying ssh based connection), as you need to use the kill or pkill parameters signals -3 (SIGQUIT), not -9 (SIGKILL) as explained in [WayBack] ssh – How to stop/kill an autossh tunnel? – Super User (thanks mariusmatutiae and dviljoen).

Monitoring the state of the ssh connection needs some parameters (like ClientAliveInterval and ClientAliveCountMax). A good start on that is [WayBack] networking – autossh does not kill ssh when link down – Server Fault.

Setting up a service so root automatically logs on a remote system:

With non-root, it might actually be possible to do this  as a service too given there is a user= parameter in service files:

Though as non-root, most people seem to use cron [WayBack] ssh – Problems with Autossh: running from cron vs terminal – Super User

Please do not use /etc/init.d/after.local as mentioned often (for instance in [WayBack] TUMBLEWEED run a script a boot): this mechanism has been deprecated and won’t work on more recent systems (like 2012 and younger: [WayBack] openSUSE Forums – systemd and using the after.local script in openSUSE 12.1). The same holds for /etc/init.d/boot.local: don’t use, even though many people indicate it works, for instance [WayBack] Run a command at boot.

An interesting approach is at [WayBack] Autossh Startup Script for Multiple Tunnels | Surnia Ulula, though I will stick with what’s below.




Most of the above comes from these links:


Continuation of:

Description=Keeps a tunnel to '' open
# -p [PORT]
# -l [user]
# -M 0 –> no monitoring
# -N Just open the connection and do nothing (not interactive)
ExecStart=/usr/bin/autossh -M 0 -N -q -o "ServerAliveInterval 60" -o "ServerAliveCountMax 3" -p 22 -l autossh -L 7474: -i /home/autossh/.ssh/id_rsa

view raw
hosted with ❤ by GitHub


Create a template service file at /etc/systemd/system/secure-tunnel@.service. The template parameter will correspond to the name
of target host:

Description=Setup a secure tunnel to %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 failure


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

Or enable it, so it get’s started at boot time:

systemctl enable secure-tunnel@jupiter.service


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: