Arch Linux

This was also mentioned on the forums: https://bbs.archlinux.org/viewtopic.php?pid=1519688#p1519688

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.

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!

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)

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...).

Works for me; SSH_AUTH_SOCK is properly set to /run/user/$UID/keyring/ssh .

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...

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?

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 :)

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…

Did you alter your PAM configuration (/etc/pam) in any way?

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

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).

yep, nothing modified

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?

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.

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?

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"

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.

Sounds more like gnome-session should be fixed to make its D-Bus interface available before starting apps.

It has been fixed upstream anyways.

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?

Hi, for me, it has been working well for quite some time now… I don't think I did anything specific…

hi Vnoel, so you can open a terminal window in gnome and you see the SSH_AUTH_SOCK variable exported if you give 'env' ?

Exactly, I get:

➜ ~ env | grep SSH
SSH_AUTH_SOCK=/run/user/1000/keyring/ssh

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

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.

@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.