300

I set up my ssh stuff with the help of this guide, and it used to work well (I could run hg push without being asked for a passphrase). What could have happened between then and now, considering that I'm still using the same home directory.

$ cat .hg/hgrc 
[paths]
default = ssh://hg@bitbucket.org/tshepang/bloog

$ hg push
Enter passphrase for key '/home/wena/.ssh/id_rsa': 
pushing to ssh://hg@bitbucket.org/tshepang/bloog
searching for changes
...
Gilles 'SO- stop being evil'
  • 829,060
tshepang
  • 65,642
  • Isn't creating a key without pass phrase just dedicated to one host an option? It worked for me on github – papo May 19 '20 at 20:31

6 Answers6

455

You need to use an ssh agent. Short answer: try 

$ ssh-add

before pushing. Supply your passphrase when asked.

If you aren't already running an ssh agent you will get the following message:

Could not open a connection to your authentication agent.

In that situation, you can start one and set your environment up thusly

eval $(ssh-agent)

Then repeat the ssh-add command.

It's worth taking a look at the ssh agent manpage.

Paul Sheldrake
  • 9,003
jmtd
  • 9,305
56

A way to solve this is with ssh-agent and ssh-add:

$ exec ssh-agent bash
$ ssh-add
Enter passphrase for ~/.ssh/id_rsa:

After this the passphrase is saved for the current session. and won't be asked again.

stefano
  • 661
48

Create (or edit if it exists) the following ~/.ssh/config file:

Host *
    UseKeychain yes
    AddKeysToAgent yes
    IdentityFile ~/.ssh/id_rsa
ness-EE
  • 581
  • But I'm using a different pair of keys for every service... – connexo Jun 16 '18 at 16:53
  • 1
    @connexo you can replace the wildcard asterisk with your individual host name and 'id_rsa' with your corresponding private key – ness-EE Jun 25 '18 at 13:26
  • 9
    I needed to add IgnoreUnknown AddKeysToAgent,UseKeychain just above UseKeychain yes. – consideRatio Jul 22 '18 at 23:36
  • 7
    I'm getting this error: "Bad configuration option: usekeychain" on the "UseKeychain yes" line. – m4l490n Oct 31 '18 at 15:09
  • 1
    @m4l490n: it seems that the UseKeychain option was added in OpenSSH 7.1p2 (2016-02-28). Maybe you have a previous version.

    http://www.openssh.com/txt/release-7.2

     – chus Nov 15 '18 at 11:43
  • 5
    This should be the accepted answer – Pepijn Olivier Jan 10 '20 at 12:50
  • 2
    it works in addition of the option in consideRatio's comment. @m4l490n you can try as well with that option, I had the same error message without the option. – рüффп Mar 24 '20 at 10:23
  • 2
    I'd like to add that this has saved my sanity regarding Git LFS, which otherwise asks for you to input your SSH key password for every LFS file in a push. – NoodleCollie Jan 08 '22 at 20:59
39

I use Keychain for managing ssh keys. It is also available in Debian and so presumably Ubuntu with

apt-get install keychain

Here is the Debian keychain package page. As you can see, the project is not very active, but works for me. I also commented a bit about this in another answer here

Community
  • 1
Faheem Mitha
  • 35,108
  • 5
    // , This worked for me. It's way better than ssh-agent, since I do not need to enter my ssh key password every time I open a terminal. – Nathan Basanese Sep 10 '15 at 19:12
  • @NathanBasane are you saying that using keychain you don't need to enter the ssh key password every time you open a terminal? How do you configure that? because keychain keeps asking for the password every time I open the terminal, only the first time I open it after booting though, but still. I don't want to enter the passphrase every time. – m4l490n Jan 01 '18 at 19:20
  • @m4l490n No, if you are using keychain, you should not need to enter the ssh key password every time you open a terminal. But you do need to enter it once after booting. The passphrase isn't saved to disk - that would insecure. – Faheem Mitha Jan 01 '18 at 20:27
  • 1
    For me, it asks every time I log in (I have a git repository + ssh keys in a remote server and every time I do a "git pull" I need to enter the passphrase) – Martin Thoma Jun 05 '19 at 18:30
  • @MartinThoma That looks wrong. Check that you have configured .ssh correctly. In particular, is your shell configured correctly? If it's still not working for you and you can't figure it out, you could ask a question. – Faheem Mitha Jun 05 '19 at 22:30
  • What about on Windows? – s3c Jun 20 '21 at 16:17
8

For convenience, the optimal method is a combination of the answers of jmtd and Faheem.

Using ssh-agent alone means that a new instance of ssh-agent needs to be created for every new terminal you open. keychain when initialized will ask for the passphrase for the private key(s) and store it. That way your private key is password protected but you won't have to enter your password over and over again.

The Arch wiki recommends initializing keychain from /etc/profile.d/ or your shell profile, such as .bash_profile or .bashrc. This has a disadvantage in that it intializes your keychain as soon as you open a terminal.

A more flexible approach is to combine keychain with a specific tmux session. So, in .bash_profile:

tsess=$(tmux ls 2>&1)

if [[ "${tsess%%:*}" = "secured" ]] && 
   [[ -f $HOME/.keychain/$HOSTNAME-sh ]]; then
    # start keychain
    /usr/bin/keychain -Q -q --nogui ~/.ssh/id_rsa
    . $HOME/.keychain/$HOSTNAME-sh
fi

...and then it is just a case of starting the secured tmux session as and when required (launched from a keybind):

#!/bin/bash
PID=$(pgrep tmux)
new="tmux -f $HOME/.tmux/conf new -s secured"
old="tmux attach -t secured -d"

if [[ -z "$SSH_AUTH_SOCK" ]]; then
    eval `ssh-agent`
    trap "kill $SSH_AGENT_PID" 0
fi

if [[ -z "$PID" ]]; then
    urxvtc -title "SSH" -e sh -c "${new}"
else
    urxvtc -title "SSH" -e sh -c "${old}"
fi

ssh-add

Now, your keychain will only be initialized once when you start that specific tmux session. As long as that session persists, you will be able to access those ssh keys and push to your remote repositories.

Community
  • 1
jasonwryan
  • 73,126
  • How would I get this to work on a remote machine? I modified the second script to check for $SSH_CLIENT and if it exists don't execute urxvtc, just tmux. That works, but the problem is the .bash_profile portion. When I first login to the box it says "server not found: Connection refused" which is the output of "tmux ls". Then, when I execute the second script, tmux either starts a new session or attaches to an existing one, but there is no keychain prompt. Then, when I exit the session, the keychain prompt is there waiting. – J.C. Yamokoski Feb 20 '12 at 15:13
  • I've updated the answer to silence tmux output if there is no session. – jasonwryan Feb 20 '12 at 18:08
  • Thank you, but that still didn't solve the issue with keychain. tmux creates the new session but goes straight to any empty prompt. Only when I exit from the tmux session do I see the keychain prompt asking for my passphrase. – J.C. Yamokoski Feb 20 '12 at 20:08
  • I guess I should stop saying keychain, since keychain is only executed in .bash_profile. The issue is from executing ssh-add. Although, if I run ssh-add manually after creating the tmux session, it works. – J.C. Yamokoski Feb 20 '12 at 20:17
  • 1
    Skip the second script and just start your secured tmux session from .profile - that way you'll get the prompt for keys as soon as you login. – jasonwryan Feb 20 '12 at 20:29
  • // , Adding keychain to my .profile worked for me on a remote machine, @jonyamo. Perfect solution for this. Now I get asked my ssh-key password once on my first ssh login. However, if I do more ssh logins to that machine, I do not need to enter my ssh-key password. Let me know if you want to do more with this. keychain and the ForwardAgent directive can make security much easier. – Nathan Basanese Sep 10 '15 at 19:13
1

You can use sshpass:

$ sudo apt-get install sshpass
$ sshpass -p 'password' ssh username@server

You just need to add sshpass -p yourpassphrase before appending your usual ssh command.

belka
  • 119
  • 3
    That sounds like a really stupid idea. Wouldn't that make your password show up in clear text in your shell history? – connexo Jun 16 '18 at 16:54
  • Exactly, but are you not supposed to protect your session with a password as well? – belka Jun 18 '18 at 08:01
  • 2
    Even if you do, how often do you have a colleague sitting next to you and helping you/learning from you? – connexo Jun 18 '18 at 14:31
  • @belka someone may steal your laptop/disc and learn your password from .bash_history. – Dmitry Fedorkov Oct 28 '19 at 13:49
  • That doesn't work. – shoosh May 05 '20 at 12:43
  • 3
    I upvoted this. I'm am testing a suite of installation scripts that use SSH a lot. I create and destroy SSH key/pairs continuously. I NEED zero interactivity. I don't care at all if someone sees their passphrases, because they are useless. I'm sick of seeing cowardly down-votes by narrowed minded people who disapprove of people who "don't use computers the way I think they should". – Martin Bramwell Aug 22 '20 at 19:17
  • 1
    @MartinBramwell finally someone that thinks like me. Computers are only tools, we have to figure out how to use them according to our needs! – belka Aug 24 '20 at 08:21
  • I should mention that you could also have been downvoted for not actually answering the question. :-) If I am not wrong SSHPASS only works with UID/PWD calls. I did not succeed trying to get it to submit a passphrase for a private key. – Martin Bramwell Aug 25 '20 at 15:25
  • If you don't care about the security of the passphrase and don't want to have to enter it, then don't bother adding it in the first place ... why do something pointless and unwanted and then search for a workaround? – Matthew Read Oct 05 '22 at 20:59
  • 1
    @connexo - to prevent any command from appearing in history, prepend the command with a space. E.g. <SPACE>echo Hello. Pressing up to go to previous command -> it isn't there. You could then close that terminal window, so it is gone forever. Alternatively, clear the current terminal window (including scrollback) by entering: clear && printf '\e[3J'. – n1k31t4 Jun 04 '23 at 15:09