Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

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.

Description=smd loop
After=local-fs.target network.target

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

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.

share|improve this question
I suppose you mean that it needs to access not your public, but private key. Am I correct? –  Serge Oct 27 '12 at 13:42
ah yes it needs the private key. let me fix that –  romeovs Oct 27 '12 at 14:02
add comment

3 Answers

up vote 1 down vote accepted

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

share|improve this answer
thanks! to be correct env should be /usr/bin/env because systemd doesn't know where env is. also, the command actually is smd-loop, smd-loop-win is the name of the created screen instance. –  romeovs Oct 27 '12 at 19:33
@romeovs fixed, thanks –  Serge Oct 27 '12 at 21:03
add comment

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.

share|improve this answer
add comment

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).
share|improve this answer
add comment

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.