ssh-agent fighting gnome-keyring on Ubuntu Gnome 16.04

[Jean-Pierre Rupp]

Sometimes I open a terminal and try to login to a remote server, just to be greeted by a command-line-based prompt asking for my password. Whenever that happens, it is ssh-agent instead of gnome-keyring that is providing the SSH agent capabilities:

$ echo $SSH_AUTH_SOCK
/tmp/ssh-qeG7CTbx4w7D/agent.4592
$ ps -p 4592 -f
UID PID PPID C STIME TTY TIME CMD
xeno 4592 4576 0 20:53 tty3 00:00:00 /usr/lib/gnome-session/gnome-session-binary --session=gnome
$ ps -p $SSH_AGENT_PID -f
UID PID PPID C STIME TTY TIME CMD
xeno 4652 4592 0 20:53 ? 00:00:00 /usr/bin/ssh-agent /usr/bin/im-launch gnome-session --session=gnome

I usually close the GNOME Terminal and open a new one (sometimes I must do this more than once), and I eventually get the expected output:

$ echo $SSH_AUTH_SOCK
/run/user/1000/keyring/ssh
$ ps -p $SSH_AGENT_PID -f
UID PID PPID C STIME TTY TIME CMD
xeno 4652 4592 0 20:53 ? 00:00:00 /usr/bin/ssh-agent /usr/bin/im-launch gnome-session --session=gnome

Interestingly, the $SSH_AGENT_PID variable seems to continue pointing to the process where ssh-agent is running.

Generally once I get the keyring socket in the $SSH_AUTH_SOCK environment variable, it will stay that way even when I close the terminal and launch a new one.

This seems to be a weird conflict between two programs offering the ssh-agent service.

[Jean-Pierre Rupp (xenog)]

I have located a way to disable ssh-agent by commenting out the use-ssh-agent line from file "/etc/X11/Xsession.options". But even after doing this it is not guaranteed that the $SSH_AUTH_SOCK variable will be set when I open a new terminal, even while doing so several minutes after I have logged into my GNOME session, presumably when all session programs are running. Sometimes I open a terminal and see that $SSH_AUTH_SOCK is set, then close it and open a new one a few minutes later, and there is no $SSH_AUTH_SOCK anymore.

[Launchpad Janitor (janitor)]

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

[Kirill Afonshin (pmvd)]

Here is the workaround:
1. disable start of ssh-agent from openssh by commenting out the use-ssh-agent line from file "/etc/X11/Xsession.options".
2. start ssh-agent from gnome-keyring daemon and set SSH_AUTH_SOCKET variable by adding the following to ${HOME}/.profile:
# From man gnome-keyring-daemon:
# Connect to an already running daemon and initialize it.
# This is often used to complete initialization of a daemon that was
# started by PAM using the --login argument.
# Output is SSH_AUTH_SOCKET=path_to_the_socket
if [ -z "$SSH_AUTH_SOCK" ]; then
    export `/usr/bin/gnome-keyring-daemon --start`
fi

[Jeremy Bícha (jbicha)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. Please execute the following command only once, as it will automatically gather debugging information, in a terminal:
apport-collect 1586835

When reporting bugs in the future please use apport by using 'ubuntu-bug' and the name of the package affected. You can learn more about this functionality at https://wiki.ubuntu.com/ReportingBugs.

[Michael Ambrus (ambrmi09)]

Hi, thanks for the info in this thread. It lead me into a work-around that seems to work for me.

The scenario in my case: something is defining SSH_AUTH_SOCK but there's no ssh-agent running, despite use-ssh-agent being set in /etc/X11/Xsession.options. gnome-keyring-deamon is however running, where it's started is however unknown to me.

The reason seems different (opposite) but the ssh-behavior is the same: It's not possible to log-in with keys.

In my case I'm running unity and LightDM but have have a set-up where both unity, i3 and gnome has been VM/DM. I also still like to alter between VM:s as the machine is used by different users liking one or the other VM more.

What's possibly worsened it is that the system has not had a clean re-install since 8.04, i.e. it's always been upgraded. (Some-where along the way I believe recalling having issues with gnome-keyring and possibly making an effort to disable it.)

As I don't know where these environment variables are being set (not even SSH_AGENT_PID which in my case is unset), my workaround is to put the following line in /etc/bash.bashrc:

if [ "X$(ps -Al -u $USER | grep ssh-agent)" == "X" ]; then
    unset SSH_AUTH_SOCK
fi

I'd appreciate feed-back if there are serious drawbacks with this approach or if a better/right way to manage this exists. (One obvious drawbacks is that tweaks like this become obsolete whence the right solution is pushed by the distribution and may cause new issues whence upgrading/updating, which may be how I ended up here in the first pace).

Thanks

[Jeremy Bícha (jbicha)]

Are you all using the GNOME3 Staging PPA? If so, this is a known issue that I don't think will be fixed there.

I believe this bug was fixed in Ubuntu GNOME 16.10 so I suggest upgrading. If you do, you will need to upgrade twice per year until 18.04 LTS.

[Jonathan Gossage (jgossage)]

I am also experiencing this problem on Ubuntu 17.04. I have seen suggestions in Internet forums that Gnome Keyring does not properly support all SSH key formats. I was using a 4096 bit RSA key in the situation that failed. When I changed to a 2048 bit RSA key the problem disappeared.

[Bruce Smith (b-e-smith)]

I have a very similar experience on Ubuntu MATE 18.04.

/run/user/1000/keyring/ssh is opened by gnome-keyring-daemon
/run/user/1000/keyring/.ssh is opened by /usr/bin/ssh-agent
$SSH_AUTH_SOCK points to /run/user/1000/keyring/ssh

When I try to open an SSH session to another machine it hangs just after "SSH2_MSG_NEWKEYS received"

Changing $SSH_AUTH_SOCK to point to /run/user/1000/keyring/.ssh allows the SSH to complete

[bissli82 (bissli82)]

I can confirm we get the same issues on Ubuntu Destktop 18.04.4 + Mate