Ubuntu – Why can’t I interact with the ssh-agent? (e.g. ssh-add -D doesn’t work)

gnome-keyringkdekubuntusshssh-agent

On my Kubuntu 14.04 system I'm trying to manage keys with my SSH agent, but somehow it appears to ignore my ssh-add commands. Look at this below and you'll see what I mean.

List the current keys
```
⟫ ssh-add -l
2048 60:6f:58:ef:7c:b0:ec:94:fb:fa:59:21:86:3d:fc:4c gert@e6230 (RSA)
```
This key is loaded at boot time, but I expected some ECDSA key, not RSA. I don't know this key…

Remove the key from the agent.

⟫ ssh-add -D
All identities removed.

yey! But… is it?

⟫ ssh-add -l
2048 60:6f:58:ef:7c:b0:ec:94:fb:fa:59:21:86:3d:fc:4c gert@e6230 (RSA)

What the hell? It just lies to me.

What's going on here?

⟫ env | grep -i ssh
SSH_AUTH_SOCK=/run/user/1000/keyring-eDJggO/ssh

Let's see what process is running that socket.

⟫ sudo fuser -u /run/user/1000/keyring-eDJggO/ssh
[sudo] password for gert: 
/run/user/1000/keyring-eDJggO/ssh:  9434(gert)
⟫ ps -p 9434 u
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
gert      9434  0.0  0.0 292528  7192 ?        Sl   00:05   0:00 gnome-keyring-daemon [...]

What the hell is GNOME keyring doing on my KDE system? Shouldn't KDE wallet be my SSH agent here?

This leads to more questions than answers and I'm left with a non-functional ssh-agent.

On another system I don't observe this behaviour and I fail to find a configuration difference. Both have only KDE installed and the packages installed are nearly identical (managed by Puppet).

Best Answer

NOTE: is not an answer solving the root issue. Please provide a new answer if you think you can solve the root cause. You really have to read on why my solution is just an ugly hack.

Here's an explanation on what happens at boot time, identifying the culprit.

Using KDM (or LightDM) as log in manager, an X session is spawned for you upon logging in. The log in manager allows you to select an X session (e.g. GNOME, KDE Plasma, etc.) based on those available in your system. The directory /usr/share/xsessions contains the files for each of those desktop environment installed and your user specific choice is saved in ~/.dmrc.

While the desktop environment loads after logging in, it loads all scripts in /etc/X11/Xsession.d/. On a Kubuntu 14.04 system I see /etc/X11/Xsession.d/90x11-common_ssh-agent there by default, initialising an SSH agent. As expected. Great!

In practice however we see different things. Where does gnome-keyring-daemon come from then and why is the regular ssh-agent not started? Well, the GNOME keyring is started in two ways:

XDG autostart, in /etc/xdg/autostart/gnome-keyring-ssh.desktop
As an Upstart session job in /usr/share/upstart/sessions/gnome-keyring.conf

All scripts are first checking the environment values whether they will proceed. E.g.

[ -z "$SSH_AUTH_SOCK" ] || [ -z "$GPG_AGENT_INFO" ] || { stop; exit 0; }

This makes it a sort of race condition which SSH agent is actually started. First one wins. Brace for more nasty bits.

How come it works at one machine reliably and it doesn't reliably at another? The X session upstart jobs are only started when the DESKTOP_SESSION environment variable is whitelisted for it in /etc/upstart-xsessions, handled by /etc/X11/Xsession.d/00upstart. KDM allows one to set a Desktop environment 'Default' (default in ~/.dmrc), effectively kde-plasma, but not appearing kde-plasma.

With Session=kde-plasma:

⟫ echo $DESKTOP_SESSION
kde-plasma

With Session=default in a KDE Plasma desktop:

⟫ echo $DESKTOP_SESSION
default

This is plain wrong. And you can guess now why it fails the whitelist check against /etc/upstart-xsessions.

Quick fix for running terminal session

killall gnome-keyring-daemon && eval `ssh-agent`

Conclusion

It appears that one can hit a bug with all Upstart session jobs not being started at all. Another bug prevents proper interfacing with the GNOME keyring SSH agent (or ssh-add should complain and fail). Oh I hate you, bugs.

Once I find time to do some research on what is exactly supposed to do what, I'll file the bug reports.

For now I decided to just 'use' the Upstart bug and prevent Upstart session jobs from running by setting Session=default. I'm not sure how much this breaks, but so far I haven't seen anything falling apart.

The root cause is the appearance of GNOME keyring in the first place and which should not lie to me and keep offering wrong keys.

Related Solutions

Ubuntu – SSH-Agent can’t open a connection to authentication agent

I addition to what txwikinger said, you can also just use the -A command line option when SSHing to your firewall.

Ubuntu – Why won’t ssh-agent save the unencrypted key for later use

Even if agent is up, if certain environment variables are not set, you have no reference to agent. Furthermore, even if it is all ok, agent and variables, the identity are not automatically sent to agent: that is a task for ssh-askpass, working only in X sessions.

If you are using bash, create the file ~/.bash_profile with this content:

# File: ~/.bash_profile

# source ~/.profile, if available
if [[ -r ~/.profile ]]; then
  . ~/.profile
fi

# start agent and set environment variables, if needed
agent_started=0
if ! env | grep -q SSH_AGENT_PID >/dev/null; then
  echo "Starting ssh agent"
  eval $(ssh-agent -s)
  agent_started=1
fi

# ssh become a function, adding identity to agent when needed
ssh() {
  if ! ssh-add -l >/dev/null 2>&-; then
    ssh-add ~/.ssh/id_dsa
  fi
  /usr/bin/ssh "$@"
}
export -f ssh

# another example: git
git() {
  if ! ssh-add -l >/dev/null 2>&-; then
    ssh-add ~/.ssh/id_dsa
  fi
  /usr/bin/git "$@"
}
export -f git

modify the file name ~/.ssh/id_dsa following your needs, and add this line to ~/.bash_logout

# stuff to add at end of ~/.bash_logout
if ((agent_started)); then
  echo "Killing ssh agent"
  ssh-agent -k
fi

A last note: this do not interfere with a gnome session, because in that case only ~/.profile is sourced, and you can benefit from the ssh-askpass graphical interface that ask for a passphrase and send it to the ssh-agent.