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).
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 regularssh-agent
not started? Well, the GNOME keyring is started in two ways:/etc/xdg/autostart/gnome-keyring-ssh.desktop
/usr/share/upstart/sessions/gnome-keyring.conf
All scripts are first checking the environment values whether they will proceed. E.g.
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
), effectivelykde-plasma
, but not appearingkde-plasma
.With
Session=kde-plasma
:With
Session=default
in a KDE Plasma desktop: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
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.
I always end up sudo apt-get remove --purge gnome-keyring anyway, followed with a restart. ubuntu-sso depends on it but I don't use that, so no worries.
ssh-agent seems to just work as it should afterwards.
I realize this is an old thread. I am using xubuntu 16.04. Seems the bug is still there. I installed seahorse to manage the keys and that worked.
This is an older question, but I still ended up here looking for a solution.
One of the issues in my distro at least is that if you are using GDM, which is Gnome's Display Manager it doesn't care about KDE/Plasma at all and does nothing to make sure it is launched properly with all its configuration utilities.
What you have to do for GDM at least is make sure you include PAM related settings.
You can do this two ways. You can install both and look at each set of configuration files and compare what is missing, or you can just give what I say a try. Going with looking at the config files will probably be the best bet into the future if things change, but either way things should be similar.
For the first file you need to edit it is
/etc/pam.d/gdm-autologin
Inside this file you will need to add 1 line under @include common-session
Add this line under the gnome key ring line.
The next file you need to edit is
/etc/pam.d/gdm-password
Inside this file you need to add 1 line under
@include common-auth
Add this line under the gnome key ring.so line.
That should take care of your login issues if you are using Plasma.
You could probably just include these things in some other way, but this is what worked for me on Ubuntu 22.04.
Hope this helps.