ssh-add does not always unlock ssh keys

Is your ssh agent running? What does "echo $SSH_AUTH_SOCK" say?

Here's the output:

claudio@Chuck:~$ echo $SSH_AUTH_SOCK
/tmp/keyring-TjsKLR/ssh

Status changed to 'Confirmed' because the bug affects multiple users.

Please reconsider the importance - it is a quite annoying bug (at least to me).

> Please reconsider the importance - it is a quite annoying bug (at least to me).

Same here. We have rather complex tunneling mechanisms where we hop over 5+ systems to get to the target hosts. With a strong (and long) passphrase and some dozen connections a day (remote support) over here this results in a major degradation of productivity.

> Please reconsider the importance - it is a quite annoying bug (at least to me).

+1
This bug is very annoying and a drain on productivity.

I just tested it here -- Oneiric, two terminal windows, one running RoxTerm, one under byobu.

On the byobu window:

ssh-add -l
(my key was shown)
ssh-add -D
ssh-add -l
(no keys shown)
ssh test.machine.info
(pop up asking for SSH passphrase; entered it, got in session; ended the session)
ssh test.machine.info
(session opened with no pop-ups; ended the session)
ssh-add -D
ssh-add -l
(no keys shown)
ssh-add
ssh-add -l
(my key was shown)
ssh test.machine.info
(session opened with no pop-ups; ended the the session)

Moved over to the stand-alone RoxTerm; then repeated the tests. To my surprise even *after* adding my SSH key in, when I tried to open the SSH session to the test machine I was still presented with a pop-up asking for the passphrase on *first* SSH. Second SSH session, *without* running 'ssh-add -D', opened the session without a pop-up for passphrase.

Another interesting bit: on the RoxTerm stand-alone, 'ssh-add -D' did *not* clean up the keys in the agent.

Additional findings: SSH-AUTH_SOCK differs on the terminal windows (byobu and RoxTerm):

* Under RoxTerm:

[cerdea-aws]cerdea@xango3:~$ set | grep SSH
SSH_AGENT_PID=2857
SSH_AUTH_SOCK=/tmp/keyring-6fXAtd/ssh
[cerdea-aws]cerdea@xango3:~$

* under byobu:

[cerdea-aws]cerdea@xango3:/build/buildd/ubuntu-qa-tools/vm-tools$ set | grep SSH
SSH_AGENT_PID=2857
SSH_AUTH_SOCK=/home/cerdea/.byobu/.ssh-agent
[cerdea-aws]cerdea@xango3:/build/buildd/ubuntu-qa-tools/vm-tools$

Note that the SSH_AGENT_PID is the same.

Also, I dimly remember something about gnome-keyring and ssh-add. Will try to find out the references.

Setting importance to Medium.

http://live.gnome.org/GnomeKeyring/Ssh has some bits on this.

This bug is rather obnoxious.

Very annoying, I run ssh-add and am still prompted for the passphrase by some GUI tool.

The bug still seems to be present in March 2012 - and is annoying indeed.

My use case is that I have a script (using tmuxinator) that opens several shells inside tmux and executes ssh in them, all at once. I run ssh-add before starting the script, so that I only have to enter the passphrase once. However with this behaviour I have to enter the passphrase into the gui dialog box multiple times.

After that ssh and the agent work as expected. But I can't seem to unlock the ssh key properly before starting an actual ssh session.

I found a way to trigger the gnome dialog box directly, so I only have to enter the ssh password once.

I created ~/bin/gssh-add and put the following in it:

SSH_ASK_PASS=/usr/bin/ssh-askpass ssh-add

I then make it executable:

chmod +x ~/bin/gssh-add

And then I launch it using Alt+F2. That triggers the gnome dialog box.

Note that if you run gssh-add from the terminal it will not trigger the gnome dialog box. See the ENVIRONMENT section of the ssh-add man page for details as to why.

Very annoying bug. One way round it is from your terminal prompt do:

$ exec ssh-agent bash

Then `ssh-add` will work as expected.

Scratch my last workaround (#13). It didn't work. This one does though

Stop gnome-keyring ssh-agent from starting. Then ssh-agent and ssh works as expected.

To stop gnome-keyring ssh-agent from starting do:

    sudo mv /etc/xdg/autostart/gnome-keyring-ssh /etc/xdg/autostart/gnome-keyring-ssh.desktop.disabled

I first posted this, plus a load of stuff about trying to work through the problem at http://askubuntu.com/questions/122824/how-to-manually-trigger-ssh-add-dialog-box/

This bug is present in Ubuntu 13.04.

Ubuntu 16.04 also impacted