It seems like i'm having a bit of a discrepancy between the behavior of ssh-agent for two accounts I have configured.

I wrote a simple monitoring script to check on the availability of some VMs we have running. I did all the testing and debugging with my main access account. In the process, I generated an SSH keypair, kicked off ssh-agent, and added the identity to the agent to allow for the script to ssh without the need for a password.

Now, I would like to run this script as a service account user. I created the service account, and to generate the keys temporarily set the login shell to /bin/bash. I generated my keys, removed the passphrase, and added the identity to the agent.

The discrepancy seems to be with how the shell connects to the agent. In my user account, I haven't had to restart the agent since I started testing (about two weeks). But, when I attempt to run the script under the service account, I seem to have to restart the agent each time, add the identity, and then perform the work.

Ideally I would like the agent to run indefinitely and have the service account reconnect to it automatically whenever the script runs so I don't need to manage processes within the script. I've looked at the configurations of each account and can't find any differences. Any insight would be greatly appreciated.

**Edit: I forgot to point out that the agent does continuously run, but shell processes for the service account do not seem to be utilizing it and a new one has to get started:

ovmmon   14043  0.0  0.0  53916   204 ?        Ss   May17   0:00 ssh-agent
ovmmon   14952  0.0  0.0  53916   204 ?        Ss   May17   0:00 ssh-agent
  • How are you starting the agent in the service account? – Jenny D May 20 '13 at 13:34
  • The same way I started it in the user account - just issuing the command ssh-agent bash and then ssh-add ~/.ssh/admin – tdk2fe May 20 '13 at 13:39
  • 1
    I generated my keys, removed the passphrase - If you keys do not have a pass-phrase, then you really don't need an agent. Just setup an ssh config file under your service account with an IdentityFile option specifying the path to the keys. If that still doesn't help, then login as the service account and try connecting to ssh with the -vv option to get verbose output. – Zoredache May 20 '13 at 16:26
  • That's a good point. I suppose since i'm merely connecting to the localhost from a service account, exposing the private key without an agent isn't a huge concern here. For future reference - I added the following flag to my ssh command: ssh -i ~/.ssh/admin (admin is the file I named when generating the key) – tdk2fe May 21 '13 at 13:21

One of two things is happening here:

  1. The ssh-agent is actually being closed when you logout
  2. The ssh-agent is still running, but you're losing the information about its PID and pipe

You can check which one is the case by doing a ps -ef and check for ssh-agent.

If the ssh-agent is dead, you need a way to keep it alive. Here are three ways of doing that:

  1. You can start the ssh-agent from a startscript when the server is booted, and echo the output to a file (with appropriate access rights to prevent it being misused). If you make the key passwordless, you can add the key from the script, too. (Obviously the last part is only advisable when the account you're connecting to has very limited rights on the remote server). Then have your script read the SSH agent information from the file created on startup.
  2. Use screen when you login to the service account; then disconnect from the screen session once you've started the agent.
  3. Use nohup when starting the agent.

If the ssh-agent isn't dead, but you've lost the environment information, make sure that when you start it you have it write its environment variables to a specific file. Then, when logging in, have your shell source that file.


If you are using a sub-shell invocation method, the ssh-agent will die upon logout of the shell. If you use eval method, the shell will stay running until manually terminating.

See: http://docstore.mik.ua/orelly/networking_2ndEd/ssh/ch06_03.htm

Specifically: http://docstore.mik.ua/orelly/networking_2ndEd/ssh/ch06_03.htm#ch06-50031.html

Also, I know when running from cron ENV variables can cause issues. So that is another area to check.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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