Thanks! This works great for me I have two ipfs services, one to launch ipfs as a daemon and one to start forwarding ssh in the background.

ipfs.service

[Unit]
Description=IPFS daemon

[Service]
ExecStart=/usr/local/bin/ipfs daemon
Restart=on-failure

[Install]
WantedBy=default.target

ipfs-ssh-forward.service

[Unit]
Description=IPFS SSH forwarding
After=ipfs.service
Requires=ipfs.service

[Service]
ExecStartPre=/bin/sleep 10
ExecStart=/usr/local/bin/ipfs p2p listen /x/ssh /ip4/127.0.0.1/tcp/22 -f
Restart=on-failure
RestartSec=10

[Install]
WantedBy=default.target

This seems to work really nicely with systemd, the port listening will automatically restart with if for some reason that systemd service stops running and will relaunch with the ipfs service when it starts. Only quirk is I'm depending on delays to wait for ipfs daemon to fully startup before launching p2p listen. If there a file that gets created/modified when the daemon fully starts it could be tracked with one of the path directives in systemd (https://www.freedesktop.org/software/systemd/man/latest/systemd.path.html#PathExists=)

Can't really comment to much on the code to implement this as I'm not familiar with the code base or go-lang in general

EDIT:
I just realized there is the ~/.ipfs/repo.lock file I can use with PathExists= directive to wait until the daemon has launched.

@Hazematman you could also use ~/.ipfs/api ($IPFS_PATH/api) in PathExists it is the address of RPC API ipfs p2p CLI will use to connect to the daemon. could be more appropriate. lmk if it works better/worse (+ mind commenting with updated examples of your systemd scripts? I'd like to include them in docs if possible)

I'm still testing it for robustness but this is what I have now for systemd services

I have a ipfs-ssh-forward.service unit file that looks like

[Unit]
Description=IPFS SSH forwarding
Requires=ipfs.service

[Service]
ExecStart=/usr/local/bin/ipfs p2p listen /x/ssh /ip4/127.0.0.1/tcp/22 -f
Restart=on-failure
RestartSec=10

[Install]
WantedBy=default.target

Then I have a ipfs-ssh-forward.path systemd path file

[Unit]
Description=Monitor for start of ipfs
After=ipfs.service
Requires=ipfs.service

[Path]
PathExists=<home>/.ipfs/api
PathExists=<home>/.ipfs/repo.lock
Unit=ipfs-ssh-forward.service

[Install]
WantedBy=default.target

I'm using the ipfs.service basically unmodified described here https://github.com/ipfs/kubo/tree/master/misc

Then to enable things I do

systemctl --user enable ipfs.service
systemctl --user enable ipfs-ssh-forward.path
systemctl --user start ipfs.service

The ipfs service should startup and then once the repo.lock and api files both exist the ipfs-ssh-forward.service is started. I've tested kill the and restarting the ipfs service, closing ipfs p2p connection with ipfs p2p close -a, and restarting the machine a few times and this seems to reliable ensure that the p2p listen is always running.

The one weird thing I'm trying to debug is that it seems that the first launch of the ipfs-ssh-forward service always fails. I'm not 100% sure why but one theory is that when the api file is created, ipfs isn't ready for p2p listen commands yet.

Thank you @Hazematman, there was indeed a race condition related to creation of $IPFS_PATH/api file.
Pushed fix in 80b703a, try the latest version of this PR if it makes any difference.

Also, check docs/p2p-tunnels.md – wanted to document this feature in more friendly way with examples, incorporated your systemd examples – lmk if this looks ok to you.

If this PR looks sensible, we will include this in 0.40.