ssh-aggent stopped accepting connections

[Marius Gedminas]

Suddenly my ssh-agent stopped accepting connections:

  $ ssh-add -l
  Could not open a connection to your authentication agent.

It is still running (pid 4530, which matches the value of $SSH_AGENT_PID), but doesn't appear to be listening on the socket (/tmp/keyring-Kp3t4b/socket.ssh according to $SSH_AUTH_SOCK). The socket exists in the filesystem, but neither lsof, nor fuser, nor netstat -x show anything about it. What lsof shows is that ssh-agent is listening on
/tmp/ssh-PcVXlL4456/agent.4456, which doesn't appear in my environment at all.

pstree indicates that pid 4530 was launched as

  /usr/bin/dbus-launch --exit-with-session /usr/bin/pulse-session /usr/bin/seahorse-agent --executex-session-manag

but /proc/4530/exe confirms it is running the /usr/bin/ssh-agent process.

I used ssh-agent successfully this morning, and it stopped working when I openend gnome-terminal with several tabs each trying to ssh into a different local host. (I've used that techinque succesfully in the past.)

I do not know how to reproduce the problem.

ProblemType: Bug
Architecture: i386
DistroRelease: Ubuntu 9.04
Package: openssh-client 1:5.1p1-5ubuntu1
ProcEnviron:
 LC_CTYPE=lt_LT.UTF-8
 PATH=(custom, user)
 LANG=lt_LT.UTF-8
 SHELL=/bin/bash
SourcePackage: openssh
Uname: Linux 2.6.28-12-generic i686

[Marius Gedminas (mgedmin)]

Checking a working GNOME session (on another machine) I see that normally it's gnome-keyring that's listening on socket.ssh. I don't have a gnome-keyring process running (and I don't see gnome-keyring-daemon either). Neither ~/.xsession-errors nor /var/log/* have any recent error messages from gnome-keyring (though the first is truncated -- "...Too much output, ignoring rest..." -- since it's filled with some strange Mono tracebacks from Migo.Syndication.RssParser).

[Marius Gedminas (mgedmin)]

Architecture: i386
DistroRelease: Ubuntu 9.04
Package: gnome-keyring 2.26.1-0ubuntu1
PackageArchitecture: i386
ProcEnviron:
 SHELL=/bin/bash
 PATH=(custom, user)
 LANG=lt_LT.UTF-8
 LC_CTYPE=lt_LT.UTF-8
Uname: Linux 2.6.28-12-generic i686
UserGroups: adm admin audio cdrom davfs2 dialout dip floppy fuse lpadmin netdev plugdev powerdev pulse-rt sambashare scanner vboxusers video

[Sebastien Bacher (seb128)]

Thank you for your bug report. The issue is an upstream one and it would be nice if somebody having it could send the bug the to the people writting the software (https://wiki.ubuntu.com/Bugs/Upstream/GNOME)

[Sebastien Bacher (seb128)]

Could you try if that's still an issue in lucid?

[Marius Gedminas (mgedmin)]

I do not know how to reproduce the problem. It never happened again to me on Jaunty or on Karmic.

[Steven Winikoff (smw)]

I've seen exactly the same symptoms with Karmic and now also with Lucid. Apparently what happens is that gnome-keyring-daemon starts correctly at the beginning of a new session, but eventually exits silently. This happened to me today in the session from which I'm typing this; gnome-keyring-daemon was running this morning, but stopped running during the day while I was out, without leaving behind any log traces (or at least, any that I could find). This session started on June 14th, 2010, immediately after a clean install of Lucid (on the same machine which had previously seen the same problem under Karmic).

For what it's worth, I haven't (yet!) modified /etc/X11/Xsession.options, so /usr/bin/ssh-agent is running (usually alongside gnome-keyring, although by itself right now :-/). I plan to remove the "use-ssh-agent" keyword from /etc/X11/Xsession.options before starting a new session.

I'd welcome suggestions for further useful information which I might be able to collect from my system while the broken session is still running.

[Steven Winikoff (smw)]

I don't have a fix for this problem, but I did just find a workaround:

    1) start gnome-keyring-daemon manually; e.g., from a shell prompt, type

             /usr/bin/gnome-keyring-daemon --start

    2) assuming that $SSH_AUTH_SOCK is pointing to the socket created by the old (now defunct) instance of gnome-keyring-daemon, delete the directory containing it, and replace it by a symlink to the directory created by the new instance of gnome-keyring-daemon; for example,

             newsockdir=`ls -dt1 /tmp/keyring* | head -1`
             rm -rf $SSH_AUTH_SOCK
             ln -s $newsockdir $SSH_AUTH_SOCK

This isn't particularly elegant, but it seems to work.

[Steven Winikoff (smw)]

Oops, I was a bit quick on the trigger -- $SSH_AUTH_SOCK points directly to the socket, not to the directory containing it. :-( The correct workaround is as follows (i.e., this is a correction to comment #9 above):

/usr/bin/gnome-keyring-daemon --start
newsockdir=`ls -dt1 /tmp/keyring* | head -1`
rm -rf $SSH_AUTH_SOCK
ln -s $newsockdir `dirname $SSH_AUTH_SOCK`

As Bullwinkle would say, "this time for sure". :-)

[David Huggins-Daines (dhuggins)]

I am seeing this bug too, since I upgraded to Maverick, but only on one of my computers (!) They are both AMD64 and running auto-login, so I'm not exactly sure what the problem is, except maybe that the one which is not working was upgraded while the one which works was a fresh install.

[David Huggins-Daines (dhuggins)]

Well, logging out and logging back in on the non-working machine resolves the problem. I guess gnome-keyring isn't being initialized properly on auto-login? Strange because it prompts me for my login password...