I'm trying to create a shell script that, among other things, starts up ssh-agent and adds a private key to the agent. Example:

# ...
ssh-agent $SHELL
ssh-add /path/to/key
# ...

The problem with this is ssh-agent apparently kicks off another instance of $SHELL (in my case, bash) and from the script's perspective it's executed everything and ssh-add and anything below it is never run.

How can I run ssh-agent from my shell script and keep it moving on down the list of commands?


ssh-agent is supposed to start a session and when it finishes the user session is over. So any command after ssh-agent would perhaps be executed after logoff.

What you want is a session-script that contains your sessions commands like this:

ssh-add /path/to/key
bash -i # or other session starter

Then start ssh-agent session-script.

  • Thanks! Creating a separate script and ending the script with exit did the trick. – Dan Oct 23 '13 at 16:29

Put the following at the top of your script:

eval `ssh-agent`

Your script should look like this:

eval `ssh-agent`
ssh-add /path/to/key


The backticks around ssh-agent collect its output. eval collects that output, concatenates it into a single command, and then executes the command. Then you can use ssh-add to provide your key credentials.

  • 9
    This is exactly what I needed, thanks, although worth pointing out that backticks are on the way out. In the new bash form, it should be eval $(ssh-agent) – sibaz Jan 4 '16 at 13:01
  • This solution didn't work for me until I put bash -i at the end of the script. – Adolfo Correa Sep 9 '18 at 23:52

I tend to do something like this in scripts that require an agent.


# if we can't find an agent, start one, and restart the script.
if [ -z "$SSH_AUTH_SOCK" ] ; then
  exec ssh-agent bash -c "ssh-add ; $0"

... and so on.

Basically the first thing the script does it check to see if an agent is running. If it isn't exec is used to start a new process in place of the script. The agent is started, keys are added, and finally, the script is called again (see the $0).

  • But that will not preserve any script parameters. And if any of the parameters has whitespace, it won't be easy to pass them along. – Denilson Sá Maia Aug 7 '14 at 14:24
  • 2
    You could use .. "ssh-add ; $0 $*", or .. "ssh-add ; $0 $@" instead, which may work. Which wouldn't be perfect, but would certainly work in many cases. The best solution is almost always to have your agent running before anything else anyway, this is just something that might be useful in obscure cases. – Zoredache Aug 7 '14 at 16:40

I found this works for me.

eval `ssh-agent` # create the process
ssh-add ~/.ssh/priv_key # add the key
git -C $repo_dir pull # this line is the reason for the ssh-agent
eval `ssh-agent -k` # kill the process

I create the ssh-agent process, add the key, do what I need to do, then kill it. No need to check if it's running later.


It is better to use keychain in this case


apt-get install keychain


yum install keychain

Add in your .bashrc the following:

eval `keychain --eval id_rsa`
  • Better? Why is it better? – JFlo Oct 3 '17 at 18:24
  • @JFlo "Better" in that, it will save the env variables to $HOME/.keychain/<file>. Running that command again will pickup an existing ssh-agent if it is still running. It can then be reused between shells/scripts. In some scenarios that isn't super safe, so you have to make that call. For me, it is an improvement over some scripts I'd written to accomplish the same task – Scott Carlson Aug 6 '18 at 13:06

I found with Zoredache's solution, the key would be available to any shell that happens to share the same ssh-agent as the shell that called the script. I wanted to avoid this in a script that required root access to a remote machine, for obvious security reasons.

I've found putting the following shebang at the top of the script works:

#!/usr/bin/ssh-agent bash

ssh-add /path/to/ssh-key
ssh root@remotehost "remote commands"

I've tried and lot and the solution that finally worked was replacing my passphrase with an empty string.

ssh-keygen -p
  • This is a very unsafe practice. Why bother using ssh at all? If you don't protect your private key, you might as well be talking in clear text. – JFlo Aug 7 '18 at 14:47
  • @JFlo: not if your client system is sufficiently secure, which it might be. Especially if you (can and do) add ACL, SELinux, or similar, which is easy with a static file but less so with ssh-agent's randomized socket. That said I wouldn't usually recommend it as first choice. – dave_thompson_085 Mar 5 at 9:49
  • While that is a very helpful process you provide, I don't think it answers anything about the OP's question. – Alexander Bird Apr 10 at 20:36

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.