systemd service that needs .ssh/id_dsa password

Question

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.

Answer 1

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*) .

Answer 2

I would generate an own ssh-key without passphrase for that service.

On the target system(s) I would then use "command=" in the authorized_keys to restrict usage of that key to a single command.

After that, to trigger the target-command you just have to connect to the server - you have to specify nothing else (not event the command) any more.

Answer 3

If you only need to have the service working while you're logged in, make it connect to the ssh-agent that you start with your session. The easiest way to do this is to use a fixed path for the agent socket. Set the SSH_AUTH_SOCK environment variable to something like /home/romeovs/.ssh/darkstar.agent.socket both in the systemd job and in your .profile. Note that if your distribution starts an ssh-agent process for you, you may need to kill it, or to leave it unused and replace it with your own. If the SSH_AUTH_SOCK variable is present in the environment, ssh-agent uses the path it contains for its socket. Then, when you log in, run ssh-add on your private key, and the job will be able to use it.

If you need to have the job work all the time, I recommend creating a specific passwordless key for that purpose (ssh-keygen -t rsa -f ~/.ssh/smd.id_rsa -N ''), and authorize it only to run a specific command on the server by using a command= and from= restrictions in the ~/.ssh/authorized_keys file on the server. The from= option means that the key is only valid for login attempts from a specific hosts, and command= specifies a command that is executed instead of the command specified by the client.

ssh-rsa AAAA…== romeovs@darkstar no-agent-forwarding no-port-forwarding no-x11-forwarding from="romeovs@darkstar.example.com" command="somecommand --foo"

The command is executed by your login shell. If you need to pass parameters to that command, you have two choices:

• The original command attempted by the client is in the SSH_ORIGINAL_COMMAND environment variable. Beware of quoting issues if you attempt to parse it.
• A few environment variables are passed by the client. The exact set depends on the server configuration (AcceptEnv directive in the sshd_config file).