Ssh – systemd service that needs .ssh/id_dsa password

gnu-screenservicessshsystemd

I have a systemctl service that starts a process smd-loop in a screen session. This process requires acces to remote SSH sources (for syncing purposes) and thus needs to be able to access my id_dsa private key.

How can I set up the systemd service so that it will work? The following service starts the process correctly but requires me to attach to the screen session and manually type in the id_dsa password.

[Unit]
Description=smd loop
After=local-fs.target network.target

[Service]
User=%i
Group=users
Type=Forking
ExecStart=/usr/bin/screen -S smd-loop-win -md "smd-loop"
RemainAfterExit=yes

When I manually start smd-loop the id_dsa password is not required since I've insalled the pam_ssh module which starts an ssh-agent that holds the password at login.

Best Answer

You need to put the identity files containing not encrypted private key into ~/.ssh directory of the user the service is running. Also, you need to set the HOME environment variable for it, for example if it is run as root:

ExecStart=/usr/bin/env HOME=/root /usr/bin/screen -S smd-loop-win -md "smd-loop"

Alternatively, if you have a control on how smd-loop invokes ssh you may add -I option to tell the ssh an identity file to use.

In any case the identity file has to be owned by this user and has to be accessible by this user only (chmod 0400 ~/.ssh/id*) .

Related Solutions

Make systemd reload only single openvpn process and not the whole group

If you use CONFIGNAME as your config file name for your .conf file you could try

systemctl restart openvpn@CONFIGNAME.service

Why is systemd stopping service immediately after it is started

Environment="USER=ubuntu" "Path=/home/ubuntu/console/bin" 
WorkingDirectory=/home/ubuntu/console/bin
ExecStart=/bin/sh -ec "exec /sbin/start-stop-daemon -S -c ${USER} -d ${Path} --pidfile=/var/run/console.pid --oknodo  --exec consoleExecutable " #2>/dev/null
ExecStop=/bin/sh -ec "exec /sbin/start-stop-daemon -K --quiet -c ${USER} -d ${Path} --pidfile=/var/run/console.pid  --retry=TERM/30/KILL/5 --oknodo --exec consoleExecutable" #2>/dev/null

This is almost worthy of the systemd House of Horror. Were it not the case that there's a horror story already in there that does this.

Do not use start-stop-daemon in a service unit to do all of the things that a service unit already does. With unnecessary PID files and the wrongheaded assumption that ExecStart accepts shell syntax comments, no less.

And do not do what the other answer says and try to bodge it with Type=forking. That makes things worse, not better.

The nonsense with start-stop-daemon is why things are going wrong. Because the process running start-stop-daemon does not become the service, but in fact exits pretty much imediately, systemd is thinking that your service is terminating. In your first systemctl status output, you can see that systemd is in the middle of sending SIGTERM to clean up all left-over running processes after running the ExecStop action, which is what it does when it thinks that a service has terminated.

Just do things simply:

Type=simple
WorkingDirectory=/home/ubuntu/console/bin
User=ubuntu
ExecStart=/home/ubuntu/console/bin/consoleExecutable

No ExecStop nor Environment is actually required.

Best Answer

Related Solutions

Make systemd reload only single openvpn process and not the whole group

Why is systemd stopping service immediately after it is started

Further reading

Related Question