Anything you want to do every time you login should in .profile (terminal logins) or .xinitrc (for GUI logins).
– BarmarSep 18 '13 at 18:50

1

Ah! I was using .bash_profile... What's the difference between .profile and .bash_profile?
– PathsofdesignSep 18 '13 at 18:54

1

Not sure why you're running the command that way in the first place. ssh-agent <command> runs <command> as a subprocess of ssh-agent, so you're starting a new shell. I think you want eval ssh-agent.
– BarmarSep 18 '13 at 20:53

7

.bash_profile is specific to bash, .profile is generic to all POSIX shells. bash will look first for .bash_profile, then default to .profile.
– BarmarSep 18 '13 at 20:54

3

The correct way to spawn ssh-agent for a "standard" (POSIX-compatible) shell is eval $(ssh-agent -s). Note also that you have to make sure you properly get rid of the agent when you log out, so it's also advisable to put trap 'kill $SSH_AGENT_PID' EXIT in your .profile after the line which starts the agent.
– kostixSep 19 '13 at 10:16

This version is especially nice since it will see if you've already started ssh-agent and, if it can't find it, will start it up and store the settings so that they'll be usable the next time you start up a shell.

Machine restart is not necessary. You can just reload .bash_profile using source ~/.bash_profile in your current shell session. Machine restart will also work because that will load the new config anyway.
– LitmusJul 16 '14 at 8:49

This script worked for me when I put it in my ~/.bashrc file (not my ~/.profile or ~/.bash_profile). The first time I open a local console it prompts for the passphrase, everything works from that point on without further prompting. Cheers.
– andrew pateFeb 19 '15 at 11:38

1

Adding the ssh-agent start command in .bashrc will make scp command not work.
– DzanvuMar 18 '15 at 8:14

2

Still annoying... you have to do this every time you log in... even if you don't use ssh. Need to make this fire off every time ssh is called... and ideally, you should be able to configure which hosts cause which keys to load.
– Erik AronestyJul 22 '16 at 15:30

I found this comment while trying to do this in Ubuntu. It seems to play much more nicely with the built in systems than hacking something into the startup scripts, at least given my knowledge of how the system should work.
– xiterionJul 25 '17 at 14:55

keychain does not work for me according to the instructions given. I added to .bash_profile and ssh still asks for password every time. i tried it multiple times in same shell. no dice. going back to basic ssh-agent approach
– javadbaJul 23 '14 at 20:12

I spent 20 minutes researching a solution because of StackOverflow comment formatting. Per xelber's comment above, the correct solution is eval `keychain --eval id_[yourid file]` to .bashrc. Backticks required to evaluate the environment variables to the current shell for access to the running ssh-agent.
– JamesAug 16 '17 at 17:27

This is the correct and simple solution. If you do not want to see the log when keychain command is executed, you can add -q option for quiet mode. More info about Keychain: funtoo.org/Keychain
– Diki AnantaJan 26 at 0:45

Thx, this is by far the most elegant solution.
– greenspandAug 3 at 18:01

I've got SSH keys in a directory outside of $HOME in Windows 10, using Git Bash. Changing the path to the RSA was all I needed to do to get this working. TYVM!
– kayleeFrye_onDeckMar 18 '16 at 4:58

4

I would argue that "If your keys do not require to type password" is close equivalent to leaving the key in ignition.
– Bruno BronoskyOct 3 '16 at 22:51

At least, it is on your own host, not somewhere on the network.
– midenokOct 4 '16 at 7:23

"I would argue that "If your keys do not require to type password" is close equivalent to leaving the key in ignition. " <-- Explain how so?? Because keys are far more flexible than passwords, far easier to revoke (what? You're only using keys for sudo users with full access? tsk tsk). Multiple sets of keys for multiple profiles of users. If you want to automate anything (like deployment, or end to end checks) then good luck constantly typing in passwords during "orchestration".
– Crossfit_and_BeerMay 10 '17 at 14:37

What would we use instead if we had multiple keys and they weren't named ~/.ssh/id_rsa? It seems that the ssh-add part of your answer expects default file names for the keys.
– Gabriel StaplesJan 24 at 0:23

Yup. I believe you can just add the file names to to the very end of the last line if needed
– Collin AndersonJan 24 at 14:51

So I used to use the approaches described above, but I kind of prefer the agent to die when my last bash session ends. This is a bit longer than the other solutions, but its my preferred approach. The basic idea is that the first bash session starts the ssh-agent. Then each additional bash session checks for the config file (~/.ssh/.agent_env). If that is there and there is a session running then source the environment and create a hardlink to the socket file in /tmp (needs to be on the same filesystem as the original socket file). As bash sessions shut down each deletes its own hardlink. The last session to close will find that the hardlinks have 2 links (the hardlink and the original), removal of the processes own socket and killing of the process will result in 0, leaving a clean environment after the last bash session closes.

Thank you for your interest in this question.
Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).