- place the
autossh@.servicefile in /etc/systemd/system - enable an instance -- suppose your remote host is called
frodothen you might run:systemctl enable autossh@frodo(do not use--nowhere!); IPv4 addresses also worked for me - now it is time to create an override specific to the instance, e.g. :
systemctl edit autossh@frodo.serviceand adjust the following bunch of settings (commented out in the main unit template) like so:
adjust the ports, username and host name as needed. The actual template unit contents are inside your editor, so you may override any of the other[Service] Environment=REMOTE_PORT=1022 Environment=TARGET_USER=username Environment=TARGET_HOST=frodo.example.comEnvironment=stanzas or provide a differentLoadCredential=stanza!
NB: you must not forget the[Service]to establish the section context.- This should have created a file
/etc/systemd/system/autossh@frodo.service.d/override.conf
- This should have created a file
- once you're done run:
systemctl daemon-reloadfor the changes to take effect - create an SSH identity in
/etc/ssh/id_nobodyusingssh-keygen -f; alternatively adjust theLoadCredential=stanza to some other credential you want to use- if you opt for a different path it probably makes sense to also place the
LoadCredential=stanza into theoverride.conf
- if you opt for a different path it probably makes sense to also place the
- run
systemd-analyze security autossh@frodo.serviceand witness something along the lines of:→ Overall exposure level for autossh@frodo.service: 1.1 OK 🙂 - start the service with systemctl start
autossh@frodo.serviceand observe any issues withjournalctl -f(if you need more context, i.e. previous lines, throw in a-n 200or so)
PS: to test the unit without installing, fake it as follows:
systemd-analyze security --offline=yes --instance=example.com autossh@.service