Help with systemd unit to shutdown router on system shutdown

i’m wanting to gracefully shutdown my router when i shutdown the system, but not on reboot, and nothing i’ve tried has worked

$ ssh router.lan 'poweroff && exit' works fine, but as a systemd unit it does nothing

this is what i’ve cobbled together so far…

Description=Shutdown router on system shutdown

ExecStart=/usr/bin/ssh router.lan 'poweroff && exit'


Hello @majik :wink:

Just think that systemd does not use your ~/.ssh folder. Therefore it doesn’t know what router.lan is.

1 Like

Usually you cannot shutdown your router - and think again - how would it power up?

Usually you cannot shutdown your router

you can if you use OpenWRT and have ssh access

how would it power up?

in my case by feeding it power (everything is fed from my UPC)

anyway, that isn’t the point - as i said, i can power it off with ssh, just not with ssh as a systemd unit and a graceful shutdown is rather important if there’s mounted storage media attached

The hostname assumes the name is broadcasted by avahi - have you tried with the router IP?

Assuming you have a public keyfile on the router you could try

ssh -i /path/to/identity user@ip.x.y.z 'poweroff'

You don’t need the exit command - the connection will terminalte automagically upon poweroff

A note only: ip/hostname is probably not the issue but still see the above from linux-aarhus. I.e., the systemd unit runs as root whereas you show things working as your user: as user youruser ssh logs in as youruser@router.lan by default but invoked by root as root@router.lan – and second certainly keys and/or configuration in your user’s ~/.ssh would not be used by the root invocation.

This is also to say that if you insist you can supposedly also run ssh through sudo -u youruser in the unit file to have things “just work” – but just be explicit as per linux-aarhus reply above.

if i run ssh user@<ip> i’m asked for a password, whereas if i run ssh router.lan i’m not, so i guess that’s one problem

i also tried dumping the unit file in /etc/systemd and recreating it in ~/.config/systemd/user as suggested in the Arch wiki followed by sudo systemctl enable '~/.config/systemd/user/shutdown-router.service' and sudo systemctl daemon-reload

i figured that might solve the problem of systemd running ssh as root but that doesn’t work either

ps: current unit file…

Description=Shutdown router on system shutdown

ExecStart=/usr/bin/ssh 'poweroff' -i '/home/user/.ssh/Linksys_id_ed25519'


That is the correct order:

ExecStart=/usr/bin/ssh -i /home/user/.ssh/Linksys_id_ed25519 user@ 'poweroff'

Look at man ssh


Order of options and arguments does not normally matter, and does not here.

Anyways; it is assumed that “user” was placeholder for your actual username. Just try manually what happens when you try to login as root with e.g.

sudo ssh -v poweroff

and/or with user@ and/or with that -i option. You’d supposedly be shown what doesn’t work.


Anyways; it is assumed that “user” was placeholder …


$ sudo ssh -v ultimately results in no key found for root user and falls back to asking for a password

same for $ ssh root@

as mentioned, $ ssh router.lan works fine with ~/.ssh/config as so…

Host router.lan
    Port 22
    User root
    IdentityFile /home/majik/.ssh/Linksys_id_ed25519

is there a way to run the systemd unit file in the console while the system is up so i can see the output?

Given that ~/.ssh/config (and assumedly no /root/.ssh/config interfering again) it really should work to do

sudo ssh -v -i /home/majik/.ssh/Linksys_id_ed25519

Does this not give you a normal login as “root” on your router? If it doesn’t the “-v” again supposedly says why not. If it does, then

ExecStart=/usr/bin/ssh -v -i /home/majik/.ssh/Linksys_id_ed25519 poweroff

should work just as well from the systemd unit – assuming of course that your /home/majik/.ssh is not on some at the time of its execution already unmounted filesystem, i.e., assuming you haven’t split off your /home. I’ve left in the “-v” in the above so you can after booting up again check what’s up with

journalctl -b-1 -xu shutdown-router.service

It is assumed that you’ve placed your service file in /etc/systemd/system/shutdown-router.service and have used

systemctl enable shutdown-router.service

to enable it. You’d of course remove the “-v” once things work.

As to your direct question, and if the above isn’t yet helping: your service file as is pulls in, i.e., shuts down, so if you want to test “live” you need to comment that out:

You can then run it immediately as

systemctl start shutdown-router.service

and in case of failure again look at things with

journalctl -xu shutdown-router.service

FWIW I grabbed your service file from above and things just work here:

$ cat /etc/systemd/system/shutdown-router.service 
Description=Shutdown router on system shutdown

ExecStart=/usr/bin/ssh -v -i /home/rene/.ssh/id_rsa rene@hp8k poweroff


I’m logging in as “rene@” whereas you want “root@” or simply nothing but I don’t see why things would be different for you given that things work from the command line as your user as you stated – again at the time of shutdown modulo a potentially already unmounted /home.

[EDIT] Oh, let me by the way add that if you do have a split-off /home you may want to copy that key file to /root/.ssh/ and refer to it there with the “-i” parameter, or also duplicate the shown ~/.ssh/config in /root/.ssh/

Just been playing with a raspberry pi - for all intent and purpose - the result should be similar for your router.

You need to ensure you have a keypair - where the keypair resides on the client system is irrelevant - but for a system service I suggest storing it in /etc with /etc/ssh/secrets as possible storage point.

You will also need to ensure the router’s sshd_config allows root to login using password. After you have copied the keyfile you can disable root password access.

#PermitRootLogin prohibit-password
man sshd_config
            Specifies whether root can log in using ssh(1).  The argument
            must be yes, prohibit-password, forced-commands-only, or no.
            The default is prohibit-password.

            If this option is set to prohibit-password (or its deprecated
            alias, without-password), password and keyboard-interactive
            authentication are disabled for root.

            If this option is set to forced-commands-only, root login
            with public key authentication will be allowed, but only if
            the command option has been specified (which may be useful
            for taking remote backups even if root login is normally not
            allowed).  All other authentication methods are disabled for

            If this option is set to no, root is not allowed to log in.

Start with switching to root context

$ su -l root

Create the storage folder

mkdir -p /etc/ssh/secrets

Change permissions on the secrects folder

chmod 700 /etc/ssh/secrets

Now generate a keypair (press Enter twice to create the keypair witout passphrase)

ssh-keygen -b 2048 -t ed25519 -f /etc/ssh/secrets/router.key

Copy the public part to your router

ssh-copy-id -i /etc/ssh/secrects/ root@ip.x.y.z

Create your service file

$ cat /etc/systemd/system/shutdown-router.service 
Description=Shutdown router on system shutdown

ExecStart=/usr/bin/ssh -i /etc/ssh/secrects/router.key root@ip.x.y.z 'poweroff'


Enable and start the service

systemctl enable --now shutdown-router.service

While not aiming to be overly argumentative as a new (manjaro) forum user certainly, I’d be a little careful with linux-aarhus’ reply just above. I.e., you already showed that you can login as root on the router and with that Linksys_id_ed2551 key by doing so as your user, so things will already be setup correctly as to any of that. If you now start reconfiguring sshd and/or generate new keys you would upset things.

The only intention is to lay out the requirements and what is required for running this as root on the router.

There is clearly an issue with the understanding of how a systemd unit works.

The command defined in ExecStart is equivalent to doing it on the commandline.

It is fine as a user to define the host in .ssh/config but when you want to run it as a system service - you need to be specific as the service will have no knowledge of predefined hosts.

It it possible to define the the task as a user service

Disable the system wide service

systemctl disable --now shutdown-router.service

Create the folder

mkdir -p ~/.config/systemd/user

Copy the service definition into the folder (to avoid confusion - delete the service definition from /etc/systemd/system)

cp /etc/systemd/system/shutdown-router.service ~/.config/systemd/user

Edit the file to look like

Description=Shutdown router on system shutdown

ExecStart=/usr/bin/ssh -i /home/%u/.ssh/Linksys_id_ed25519 user@ip.x.y.z 'poweroff'


Then enable the service using the --user prefix

systemctl --user enable --now shutdown-router.service
1 Like

Again… why not just specify


and be done with it?

Unless I’m quite seriously mistaken User= in a unit file would run ssh as said user but would not e.g. have ssh find the user’s $HOME/.ssh configuration, and certainly it would not help as to not having that home directory mounted anymore at the time of its execution just before shutdown if that’s the issue, as I’m somewhat expecting. Hence my advise/insistence of just being explicit as per linus-aarhus’ first reply, i.e., with “-i” in this case to supply the key.

If only there was an easy way to test that…

There is and I did test that above shutdown-router.service file with “User=rene”. It fails and still looks for its configuration in /root/.ssh – as expected what with running still in root’s environment. Moreover and as also said, certainly it wouldn’t help with an unmounted /home.

I’ll not comment furrher until OP’s back and confirmed/denied Help with systemd unit to shutdown router on system shutdown - #12 by rene1. As said there, given that it works for him as his user and with the by him posted ~/.ssh/config it would seem almost impossible to not work other than as said /home issue.

Then you did something wrong.

I don’t see any unmounted /home mentioned in OP’s post nor what that has to do with systemd service file.