FS#44583 - [gnome-keyring] GNOME Keyring and SSH (Git) integration doesn't work anymore.

Attached to Project: Arch Linux
Opened by Lucas (tr4ce) - Tuesday, 14 April 2015, 21:13 GMT
Last edited by Jan de Groot (JGC) - Saturday, 28 October 2017, 22:24 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Jan de Groot (JGC)
Jan Alexander Steffens (heftig)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 11
Private No

Details

Description:

Since the upgrade to GNOME 3.16, the integration of SSH and GNOME keyring doesn't work anymore. I actually only tested this with Git, so when trying to pull/push a repository with SSH, it asks in the terminal for the passphrase of my SSH key, instead of a GNOME shell window asking my to unlock my SSH key. The advantage of the GNOME keyring integration was that it unlocks your SSH key for the rest of your session, while currently it asks for my passphrase every time.

Git version: 2.3.5
libgnome-keyring version: 3.12.0 (?)
gnome-keyring 3.16.0-1

I also tried to reconfigure the integration as mentioned at the bottom of this article: https://wiki.archlinux.org/index.php/GNOME_Keyring

Steps to reproduce:
1. Have a git repository which you access through SSH;
2. Pull/push from/to the repository;
3. It asks for your passphrase in the terminal instead of a GNOME shell window.

If you need any other information please let me know.
This task depends upon

Closed by  Jan de Groot (JGC)
Saturday, 28 October 2017, 22:24 GMT
Reason for closing:  Fixed
Additional comments about closing:  Looks fixed for me, haven't seen this for a long while now.
Comment by Doug Newgard (Scimmia) - Wednesday, 15 April 2015, 02:09 GMT Comment by Tom Richards (trichards) - Friday, 15 May 2015, 15:24 GMT
The user who mentioned this in the forums experienced the issue semi-randomly for a short period of time.
>I have rebooted a few times since and SSH_AUTH_SOCK has always been correct. Maybe there is a bug/race condition which does this? Echo $SSH_AUTH_SOCK to check.

This is unlike the behavior I'm experiencing. SSH_AUTH_SOCK is never correct for me, no matter how many times I reboot.

I believe that git is a red herring here. Git is simply invoking SSH, and SSH is unable to access gnome-keyring-daemon for whatever reason.
Comment by vnoel (kaouete) - Wednesday, 27 May 2015, 08:28 GMT
Hi,

I have the same problem with ssh and gnome-keyring.

If I look at the set env variables related to SSH, I have:
[vnoel@jamon ~]$ echo $SSH_ASKPASS
/usr/lib/seahorse/seahorse-ssh-askpass
[vnoel@jamon ~]$ echo $SSH_AUTH_SOCK
/tmp/ssh-wCnfUTKxtXhI/agent.5771
[vnoel@jamon ~]$ echo $SSH_AGENT_PID
5781
[vnoel@jamon ~]$ ps aux | grep 5781
vnoel 5781 0.0 0.0 13336 340 ? Ss 10:18 0:00 /usr/bin/ssh-agent -- gnome-session

The start order of ssh-agent and gnome-keyring are:
mai 27 10:18:45 jamon /usr/lib/gdm/gdm-x-session[5762]: /etc/gdm/Xsession: Beginning session setup...
mai 27 10:18:45 jamon /usr/lib/gdm/gdm-x-session[5762]: localuser:vnoel being added to access control list
mai 27 10:18:45 jamon /usr/lib/gdm/gdm-x-session[5762]: /etc/gdm/Xsession: Setup done, will execute: /usr/bin/ssh-agent -- gnome-session
mai 27 10:18:45 jamon /usr/lib/gdm/gdm-x-session[5762]: Activating service name='org.a11y.Bus'
mai 27 10:18:45 jamon /usr/lib/gdm/gdm-x-session[5762]: Successfully activated service 'org.a11y.Bus'
mai 27 10:18:45 jamon org.a11y.Bus[5769]: Activating service name='org.a11y.atspi.Registry'
mai 27 10:18:45 jamon org.a11y.Bus[5769]: Successfully activated service 'org.a11y.atspi.Registry'
mai 27 10:18:45 jamon org.a11y.atspi.Registry[5787]: SpiRegistry daemon is running with well-known name - org.a11y.atspi.Registry
mai 27 10:18:45 jamon gnome-keyring-daemon[5759]: couldn't register in session: The name org.gnome.SessionManager was not provided by any .service files
mai 27 10:18:45 jamon gnome-session[5771]: SSH_AUTH_SOCK=/run/user/1000/keyring/ssh
mai 27 10:18:45 jamon gnome-session[5771]: SSH_AUTH_SOCK=/run/user/1000/keyring/ssh
mai 27 10:18:45 jamon gnome-session[5771]: GPG_AGENT_INFO=/run/user/1000/keyring/gpg:0:1

So I don't really get why the environment variables from ssh-agent are kept, which would explain why gnome-keyring is not used as an agent.

And secondly, I don't get why seahorse's askpass is not used: ssh insists to ask my password on the command line!

Note that if I use ssh-add, then my ssh key is stored and ssh-agent works well, but I would like to use gnome-keyring, it was working in the past :)

Thanks!
Comment by Conrad Hoffmann (conrausch) - Monday, 22 June 2015, 20:29 GMT
For what it's worth, I have the same problem. Don't know exactly when it stopped working unfortunately.

I doubt the race condition theory, because as far as I can tell /etc/gdm/Xsession (which start the "wrong" ssh-agent) starts gnome-session at the very end.

I think it's much more likely that the "couldn't register in session: The name org.gnome.SessionManager was not provided by any .service files" is the problem (I get that, too). Keyring uses (should use?) the DBUS interface org.gnome.SessionManager.Setenv to push environment variables to the session (see gnome-session/gnome-session/README), so it seems like that's failing.

Could very well be an upstream bug?

For all those finding this in need of a workaround: add the following line to your ~/.bashrc:

export $(/usr/bin/gnome-keyring-daemon --start)
Comment by vnoel (kaouete) - Monday, 22 June 2015, 21:03 GMT
Well, last update on gdm removed the ssh-agent execution in Xsession, and now, in Gnome, I don't have any SSH_AUTH_* variable initialised!

So you are right, it's not a race condition, but then, there is something really strange, because /usr/bin/gnome-keyring-daemon is running and was started in my session (but I'm not clear by what...).
Comment by Jan Alexander Steffens (heftig) - Monday, 22 June 2015, 21:53 GMT
Works for me; SSH_AUTH_SOCK is properly set to /run/user/$UID/keyring/ssh .
Comment by Conrad Hoffmann (conrausch) - Monday, 22 June 2015, 23:34 GMT
I did some tests, with the following results:

* Create a new user: works - when I login as that user, SSH_AUTH_SOCK is always set correctly
* "delete" (move) my (broken user's) ~/.local folder: works once (!), then stops again starting with the second login
* "delete" (move) my (broken user's) ~/.local folder, create an empty ~/.local: doesn't work

I am not sure what to make of this. At least it is oviously a user-specific issue. But why does it work when .local has to be completely regenerated vs not when only the content has to be regenerated? And why does it work only once?

So I assume it must be a mixture of something in my .local folder and some other settings, maybe in .config folder or somewhere else. I'll try to narrow i down some more...
Comment by Conrad Hoffmann (conrausch) - Tuesday, 23 June 2015, 07:27 GMT
I think I have a lead. It seems to be working for me as long as I don't have any applications in autostart. As soon as I start something (e.g. terminal) with autostart, SSH_AUTH_SOCKET is not set - not in the environment of the autostarted app and neither in that of any app started later on.

Can someone else affected confirm this observation?
Comment by vnoel (kaouete) - Tuesday, 23 June 2015, 07:32 GMT
Jan: it is also properly set on one of my machines, and it was not yesterday on the other… it's mostly the same setup concerning our discussion.
To me, something is undeterministic, and maybe, when I come back home tonight and boot my machine, the variable will be set.
That's why I must have previously thought of a race condition.

Conrad: can you confirm that whatever is the situation (working and non-working) the gnome keyring process is running in all cases?

I'm going to do tests with your hypothesis but first add this comment because I need to close the browser :)
Comment by vnoel (kaouete) - Tuesday, 23 June 2015, 07:43 GMT
Well, no need to wait to go home tonight, I restarted my computer and the variable was not set, then I added an autostarted application (with gnome tweak tool) just to test Conrad's setup, restarted gnome and the variable wasn't set, and then I removed the autostarted app and restarted gnome and now the variable is set :)

There is something fishy and non-deterministic :)
It may be an upstream bug too yes.

Also, the error "couldn't register in session: The name org.gnome.SessionManager was not provided by any .service files" in the logs appears in all cases, so I'm not totally sure it is related to the problem, I did once a research on the matter and it seemed to me it was a remnant of previous versions of gnome…
Comment by Jan Alexander Steffens (heftig) - Tuesday, 23 June 2015, 07:45 GMT
Did you alter your PAM configuration (/etc/pam) in any way?
Comment by vnoel (kaouete) - Tuesday, 23 June 2015, 07:57 GMT
I don't think so no, except maybe installing package that adds file in pam.d:
[vnoel@jamon ~]$ ls /etc/pam.d/
chage gdm-pin polkit-1 system-local-login
chfn gdm-smartcard rlogin system-login
chgpasswd groupadd rsh system-remote-login
chpasswd groupdel shadow system-services
chsh groupmems sshd useradd
cups groupmod su userdel
gdm-autologin login sudo usermod
gdm-fingerprint newusers su-l
gdm-launch-environment other system-auth
gdm-password passwd systemd-user
Comment by Jan Alexander Steffens (heftig) - Tuesday, 23 June 2015, 08:11 GMT
pacman -Qqo /etc/pam.d/* | sort -u | pacman -Qkk -

will tell you if any of the packages which own files in /etc/pam.d have been modified (atm it can't use checksums, just sizes and timestamps).
Comment by vnoel (kaouete) - Tuesday, 23 June 2015, 08:13 GMT
yep, nothing modified
Comment by Johannes Rohr (jro) - Wednesday, 05 August 2015, 10:29 GMT
Hi, I'm seeing the same on a pristine Arch install I set up yesterday. When I rm -rf ~/.local/share/keyrings, SSH_AUTH_SOCK is set the next time I log on, however, the next time it's just like before. Has anyone reported this to upstream yet?
Comment by Tom Richards (trichards) - Friday, 18 September 2015, 01:31 GMT
I suspected (incorrectly) that this issue was really caused by another package. I performed the following actions:

pacman -R gnome-user-share gnome-software
pacman -S gnome-session gnome-settings-daemon

and everything appeared to work for a bit... until it didn't. Sigh.
Comment by vnoel (kaouete) - Wednesday, 28 October 2015, 09:38 GMT
So, now I don't have any problem with ssh-agent taking over gnome-keyring, but still, I don't get the SSH_AUTH_SOCK var present...

Maybe it is related to this bug: https://bugzilla.gnome.org/show_bug.cgi?id=738205
But it was solved only for wayland apparently… not sure it is the same.

There is some kind of problem with the order things are executed by gnome-session, and sometimes the variables are not used.

Maybe we could have a hack in Arch while this is fixed (in https://bugzilla.gnome.org/show_bug.cgi?id=756324) for gnome 3.20?
Comment by Ulf Winkelvos (uwinkelvos) - Tuesday, 17 November 2015, 00:00 GMT
A post install note to do something like this probably would not hurt:
[xx@xx-nb ~]$ cat .profile
export SSH_AUTH_SOCK=/run/user/1000/keyring/ssh
export GPG_AGENT_INFO=/run/user/1000/keyring/gpg:0:1
export _TODO_="remove .profile"


Comment by Michael Trunner (trunneml) - Thursday, 17 December 2015, 19:40 GMT
I had the same Problem. The patch in this debian bug report fixed it for me:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=804703

I created a patched version of gnome-keyring and the ssh integration works again.
You can find it here:

https://www.dropbox.com/sh/uudpqc61hs79n0h/AADXfSbn0g-sU6GwqwQm-MYDa?dl=0

I also uploaded the PKGBUILD and the patch it self.
Comment by Jan Alexander Steffens (heftig) - Thursday, 17 December 2015, 20:21 GMT
Sounds more like gnome-session should be fixed to make its D-Bus interface available before starting apps.
Comment by Ulf Winkelvos (uwinkelvos) - Thursday, 17 December 2015, 20:53 GMT
It has been fixed upstream anyways.
Comment by Giulio Fidente (giulivo) - Wednesday, 27 January 2016, 11:44 GMT
hi Ulf, I've just built version 3.19.4 of gnome-keyring and it doesn't fix the issue for me.

which change you think is supposed to fix the problem?
Comment by vnoel (kaouete) - Wednesday, 27 January 2016, 11:47 GMT
Hi, for me, it has been working well for quite some time now… I don't think I did anything specific…
Comment by Giulio Fidente (giulivo) - Wednesday, 27 January 2016, 11:54 GMT
hi Vnoel, so you can open a terminal window in gnome and you see the SSH_AUTH_SOCK variable exported if you give 'env' ?
Comment by vnoel (kaouete) - Wednesday, 27 January 2016, 11:55 GMT
Exactly, I get:

➜ ~ env | grep SSH
SSH_AUTH_SOCK=/run/user/1000/keyring/ssh
Comment by Giulio Fidente (giulivo) - Wednesday, 27 January 2016, 12:12 GMT
FWIW, fedora 23 ships version 3.18.3 and it's built from a vanilla tarball [1], with no additional patches but it's not suffering the same issue.

I also don't see the same issue on another installation of Arch where the same build is installed; not sure if this is triggered by a race of a user config.

1. http://koji.fedoraproject.org/koji/buildinfo?buildID=694623
Comment by János Illés (ijanos) - Wednesday, 27 January 2016, 12:42 GMT
I experience this on one machine but not on another and as far as I know they have the same user config and same version both running arch.

Comment by Ulf Winkelvos (uwinkelvos) - Thursday, 28 January 2016, 20:28 GMT
@Guilio: https://bugzilla.gnome.org/show_bug.cgi?id=756324 is the related bug report. So you would have to build gnome-session and therefor pretty much all GNOME libs in 3.19. but anyways i hope it is fixed in 3.20 and until then my .profile is handling that Problem.

Loading...