Description of problem: When using XMonad with MATE, programs which use ssh internally don't seem to be able to access the ssh-agent, and request passwords unexpectedly. The same programs started from a terminal are able to access the ssh-agent and don't request passwords. Version-Release number of selected component (if applicable): xmonad-mate-0.12-2.fc25.x86_64 ghc-xmonad-0.12-2.fc25.x86_64 openssh-clients-7.4p1-4.fc25.x86_64 mate-session-manager-1.16.1-1.fc25.x86_64 How reproducible: 100% Steps to Reproduce: 1. Start xmonad-mate session 2. Open a terminal and add a key with ssh-add 3. From the MATE menus, run a program which uses ssh internally, such as vinagre (with proxy through SSH enabled) or virt-manager (with a qemu+ssh connection to the backend) 4. Attempt to connect to a host where you have ssh public key authorization Actual results: Program prompts for a password on the remote host. Expected results: Connects without password, using the key already given to the ssh-agent. Additional info: Running the same program (e.g. vinagre or virt-manager) from a terminal behaves as expected, using the key in the agent to connect without further authentication.
Can you try this build for f26 https://koji.fedoraproject.org/koji/buildinfo?buildID=834314 and see if it helps? I can backport it to f25. So this is probably a duplicate of bug 1413338.
Tried that build, didn't work so well. Using that version, I wasn't even able to load my key with ssh-add :(.
Oh, that is a little worrying. Did you see any errors or logs?
There's an error message from ssh-add: umbus:~$ ssh-add Enter passphrase for /home/dwg/.ssh/id_ed25519: Could not add identity "/home/dwg/.ssh/id_ed25519": communication with agent failed Not sure where I'd look for logs. I can supply an strace if you want - but obviously I'll need to redact my private key and passphrase from it first.
Any further ideas? Do you want the strace or some other sort of debugging done?
(Perhaps bug 1413338 is something else.) I am not sure to be honest - I guess I should try to reproduce the problem. These days I don't use xmonad-mate (or xmonad) alas. I assume Fedora Mate is okay? It might be worth trying to test on a fresh install or at least a new account. Not sure how much the strace will help, but if you think it could provide useful information for tracking down the problem, then please.
The problem is, alas, worse in Fedora 26. Now, ssh agent doesn't work from any programs. I have, however, been able to track down the problem a bit further. Initially, xmonad-mate was starting up with gnome-keyring. I think the ssh agent included in gnome-keyring was working - except that it doesn't do what I need because of bug 1248916. I disable the gnome-keyring ssh component in autostart, and now ssh-agent is started as well as gnome-keyring. Unfortunately, SSH_AUTH_SOCK is still pointed at gnome-keyring, instead of ssh-agent, hence the breakage. I did notice that in the tree of processes under lightdm, there are two notable subtrees - things under the xmonad process (including terminals started with alt-shift-enter) and things under the mate-session process (things started from menus). My guess is that in F25 (where, again, both ssh-agent and gnome-keyring were started) the things under xmonad had SSH_AUTH_SOCK set to ssh-agent, and those under mate-session pointed at gnome-keyring. Now, under F26, they're at least consistent - fixing bug 1413338, but always point at gnome-keyring, even when they shouldn't.
I'm having a fair bit of trouble working out where in the tangle of scripts between the DM and the xmonad-mate session the ssh-agent and keyring are started, and who is responsible for setting SSH_AUTH_SOCK. I suspect bug 1401222 is another dupe, though there's not much info there.
Ping, This problem is *really* frustrating.
Thank you for the comments. Sorry for the slow reply. Could you try with an ordinary Mate session? I assume that works... Maybe the way xmonad is being started is not orthodox.
Sorry I've taken so long to reply to this - I've been very busy at my day job (and I have a limited workaround that makes the current situation almost bearable). So, in fact this *does* happen with an ordinary Mate session. And, to my surprise, with a plain xmonad session. And with a GNOME3 session. Everything now, appears to insist on using gnome-keyring as the ssh key agent, despite the fact that it suffers a serious limitation (bug 1248916). It used to be that if you disabled gnome-keyring's ssh agent component in the startup programs you'd get the plain, working ssh-agent instead, but that's no longer the case. The xsessions for MATE, xmonad, and xmonad-mate start gnome-keyring with ssh agent enabled anyway. At least xmonad-mate (forgot to check the others) does _start_ ssh-agent, but SSH_AUTH_SOCK is pointing to gnome keyring instead, so it's not very useful (my workaround is based on manually altering SSH_AUTH_SOCK in each shell I start). GNOME3 seems to be even worse - when I disable gnome keyring from the startup programs, I don't get any SSH_AUTH_SOCK at all.
Not sure I can do anything then. Would it make sense to move this or file another bug?
I think it makes sense to move it, but I haven't figured out where yet. I haven't managed to decipher the X startup scripts enough to figure out where SSH_AUTH_SOCK is being set. I don't know if it's the same place for all the desktop environment options.
You use a display manager?
Yes, lightdm at present.
Just wondered if the DM is a factor or not? startex gives the same result?
Great suggestion. Turns out startx does *not* give the same result. When I run 'startx', I get a GNOME3 session - haven't worked out how to point it at xmonad-mate yet, but SSH_AUTH_SOCK is set correctly to a real ssh-agent. Still trying to work out where the script path differences are.
Okay, might be worth trying gdm too.
Tried gdm, but same results as lightdm. I think I'm going to need to break out SystemTap or something to trace through the myriad scripts and work out where SSH_AUTH_SOCK is being set.
So, I've finally had a chance to investigate this a bit more. I think the problem is in /bin/xmonad-start after all. Specifically this stanza: if [ -x /usr/bin/gnome-keyring-daemon ]; then eval $(gnome-keyring-daemon --start) export GNOME_KEYRING_SOCKET export GNOME_KEYRING_PID fi The trouble is that this invokes gnome-keyring-daemon dependent only on whether it is installed, not whether it is appropriate or configured for the desktop setup we're entering. The output of gnome-keyring-daemon includes setting SSH_AUTH_SOCK to point to itself, which is again 'eval'ed unconditionally by the script. By poking around in /proc, I've determined that SSH_AUTH_SOCK *was* set correctly (pointing to ssh-agent) in the parent process of xmonad-start. So AFAICT, the DM scripts are correctly setting it, but then xmonad-start is overwriting it unconditionally with gnome-keyring-daemon.
Thanks, David, for this. Hmm, so is it better to remove that whole stanza then?
I'm not sure. I think that would work well for me personally, but it might break things for people who do want to use gnome-keyring rather than the openssh ssh-agent - i.e. it might unfix bug 1413338.
I could add an envvar or logic/workaround to check/reset SSH_AUTH_SOCK. Reading bug 1413338 - it seems you require ssh-agent for non-RSA keys? Maybe it is really a gnome-keyring bug?
There absolutely is a gnome-keyring bug here (bz 1248916). However, that's been a known bug there for ages, and they don't seem to have much interest in fixing it. So, I still think having the xmonad scripts work (again) with the openssh agent is a good idea.
Okay so if you can tell me the required conditions, I can try to come up with something.
Sure. I'll just have to find the time to do the research, which probably won't be very soon.
I mean it seemed you already had ideas about SSH_AUTH_SOCK etc: I just need a summary of what it should be and what it is currently etc.
This message is a reminder that Fedora 26 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '26'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 26 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Moving to F27, since the bug is certainly still there. In F28, it's a bit more complicated. The scripts still seem to be pointing at gnome-keyring instead of ssh-agent, despite configuration otherwise. However it looks like gnome-keyring now supports ed25519 keys, so that no longer causes a problem for me.
This message is a reminder that Fedora 27 is nearing its end of life. On 2018-Nov-30 Fedora will stop maintaining and issuing updates for Fedora 27. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '27'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 27 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 27 changed to end-of-life (EOL) status on 2018-11-30. Fedora 27 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.