I like to have permanent SSH connections from (a VM on) my home network to the various virtual private servers (VPSs) that I have scattered around the globe as these give me SOCKS proxies that I can use to make my web traffic appear from the US or the Netherlands or wherever (as mentioned in my previous post about offshoring traffic).

I’ve been using Ubuntu VMs since Jaunty Jackalope and when I discovered AutoSSH I made myself some init scripts that would make the connections. Later on I modified those scripts to run in Screen so I could jump onto them if needed for any troubleshooting. That was all fine in the world before systemd, but with Ubuntu 14.04 LTS reaching end of life there’s no longer a pre systemd choice for a mainstream distro[1]. So I’ve bitten the systemd bullet, and upgraded my VMs to Ubuntu 18.04 LTS.

Of course… my old init scripts didn’t just work. So I had to cobble together some systemd service units instead.

[Unit]
Description=AutoSSH tunnel in a screen
After=network-online.target

[Service]
User=changeme
Type=simple
Restart=on-failure
RestartSec=3
ExecStart=/usr/bin/screen -DmS tunnel1 /usr/lib/autossh/autossh \
-M 20020 -D 0.0.0.0:12345 [email protected]

[Install]
WantedBy=multi-user.target

The unit source code is also in a gist in case that’s easier to work with.

The unit can then be enabled and started with:

sudo systemctl enable autossh_screen.service
sudo systemctl start autossh_screen.service

Going through it line by line to explain what’s happening:

• Description is a plain text explanation of what the unit is for. In my own I note which location the tunnels go to.
• After is used to ensure the network is ready for making SSH connections
• User defines which user the screen runs as, and should be changed to the appropriate username
• Type simple tells systemd that we’re not running a forking process
• Restart on-failure means that if screen crashes for some reason them systemd will try to restart it
• RestartSec tells systemd to wait 3s before doing any restarts (so it doesn’t thrash too hard on something that keeps failing)
• Execstart gets us to the actual command that’s running…
  • /usr/bin/screen is the default location for screen on Ubuntu (installed with ‘sudo apt-get install -y screen’)
  • -DmS tunnel1 tells screen to Detach but not fork, force a new session, and name the screen ‘tunnel1’ (mine are named after where they go to so that when I resume those screens with ‘screen -r’ I can pick out which VPS I’m using)
  • /usr/lib/autossh/autossh is the default location for autossh on Ubuntu (installed with ‘sudo apt-get install -y autossh’)
  • -M 20020 configures the monitoring port for autossh – make sure this is different for each unit if you’re running multiple tunnels
  • -D 0.0.0.0:12345 gives me a SOCKS tunnel on port 12345 – again make sure this is different for each unit if you’re running multiple tunnels
  • [email protected] is the username and fully qualified hostname for the VPS I’m connecting to
• WantedBy defines what we’d have previously considered the default runlevel (normal system start)

Although I’ve been using Ubuntu 16.04 and 18.04 to acclimatise to systemd for the past few years I’m by no means an expert, so it’s possible that I could have done better here. Should I have used the ‘forking’ type and stuck with -d rather than -D in the screen flags? I just don’t know. This was cobbled together with help from this autossh gist and this python in screen example I found.

Update 9 May 2019

For a good overview of systemd check out Digital Ocean’s Systemd Essentials: Working with Services, Units, and the Journal (and their other posts linked at the bottom of that overview). There’s more at my systemd PinBoard tag.

Note

[1] I’ve kicked the tyres on Devuan, but we didn’t get along.