GNOME Bugzilla – Bug 576700
SSH key not working via gnome-keyring / gnome-terminal
Last modified: 2009-07-16 17:22:26 UTC
Please describe the problem: I have a verified working id_rsa ssh key. Works via ssh-agent, also works direct via logging in. I have several profiles set up in gnome-terminal with custom command "ssh user@host" which should pick up the key. After a boot, when I try using gnome-terminal to auto log into a site, gnome-keyring (-ask?) prompts for the passphrase (correct behaviour). It will only accept the correct one I am expecting, rejects others. After accepting the ssh key, it then seems to ignore it and proceeds to attempt to log into remote server without an ssh key. Not sure if this is a gnome-keyring issue or gnome-terminal. If I revert to gnome-keyring 2.24, the correct key is used, but passphrase requested and used correct each time (so guessing its not using gnome-keyring at that point, but at least is usable for me). Without reverting, there is no way for me to use gnome-terminal to log in with an ssh key. Steps to reproduce: 1. create an id_rsa key 2. create a custom command to ssh user@host in gnome terminal 3. try and use this to login Actual results: As above, prompted for passphrase, but not used. Key works fine via other means. Expected results: Once prompted for passphrase, gnome-terminal Does this happen every time? yes Other information: Have an output of ssh -vvv if it helps.
Created attachment 131336 [details] ssh -vvv output via gnome-terminal custom command
If I understand correctly, the file ~/.ssh/id_rsa is the key you're trying to use to log into the server. Is that right? If you execute the following does the login work as expected (possibly prompting you for the key password on the command line)? $ export SSH_AUTH_SOCK= $ ssh user@host This takes gnome-keyring out of the picture for the test, and lets us double check if an ssh login to that host actually works with the key.
Yes, to confirm, with no changes... Initially... ssh user@host produces gui prompt for password, it accepts passphrase given, produces terminal with password request (inside terminal), I can't log in. echo $SSH_AUTH_SOCK produces /tmp/keyring-xxxxx/socket.ssh if I then export SSH_AUTH_SOCK= ssh user@host it then asks for passphrase, I can log in fine. if I then export SSH_AUTH_SOCK=/tmp/keryingfromabove and then retry ssh user@host it asks for password (incorrect behaviour, should ask for passphrase), and I can't log in.
There's been a bunch of fixes in gnome-keyring (related to bugs in the secure memory allocation), that seemed to cause this problem for others. One symptom was gnome-keyring-daemon entering an endless loop (with high CPU usage). These fixes are committed to the gnome-2-26 branch of gnome-keyring, and will be released (within the next 24 hours) as part of version 2.26.1. If 2.26.1 doesn't fix this problem for you, could you reopen this bug? Thanks for your contributions to fixing this issue, and sorry for the trouble.
Confirming have upgraded to 2.26.1 and still broken. Problem still exists, and tests the same as previous. If I unset SSH_AUTH_SOCK I receive a passphrase prompt for my key, I don't if its set (ignores key and goes for password). Ian
I can confirm this with 2.26.0 on amd64 (Debian package 2.26.0-3, Debian bug http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=524018). I will see if I can reproduce this at home now (amd64 but version 2.22.3, going to upgrade GNOME to 2.26 first) and then attempt to build 2.26.1 and reproduce.
ok, confirmed on my desktop computer. Now to try 2.26.1.
Yup still happens with 2.26.1.
[originally pasted to the wrong bug, apologies] Ok I've reached the limits of my investigative skills for now. I could try a 2.25 version and try to pin down when the bug was introduced, but switching gnome-keyring versions is not too easy for me. To achieve it this time, I built 2.26.1 and installed to /usr/local, and tried changing my session settings to invoke that instead of the one in /usr/bin. My session settings were simply ignored, so I ended up moving the /usr/bin copies aside and symlinking their old paths to the new binaries in /usr/local/bin. If someone could give me a brief pointer on a neater way of switching keyring versions (perhaps within an X session ideally) that would be great. If there's any configure or make flag (or set of fprintfs I could hack in) that might shed light on what is going on pointers in that direction would be great too.
*** Bug 577842 has been marked as a duplicate of this bug. ***
Created attachment 133541 [details] Private key for test case
Created attachment 133542 [details] Public key for test case
To reproduce: 1. Create two user accounts test1 and test2 2. Copy rsa1023.pub to ~test1/.ssh/authorized_keys2 3. Copy rsa1023 to ~test2/ and set permissions to 600 4. Add the private key for test2: test2:~$ ssh-add rsa1023 5. Try to log in as test1: test2:~$ ssh test1@localhost (prompts for password, ssh -v shows the key was attempted but it failed to work) 6. Try to log in as test1 providing key explicitly: test2:~$ ssh -i rsa1023 test1@localhost (succeeds without requiring password)
Tested on Ubuntu 9.04 with: gnome-keyring 2.26.1 openssh 5.1p1 seahorse 2.26.1
Just to add to this... I notice if I copy my id_rsa key to /root/.ssh and ssh user@host (as root), then I get prompted via the console for the passphrase and can login fine (no gui prompt). If I do the same via normal user and ssh user@host, gui pops up asking for pass, accepts it, then doesn't use it and passphrase never requested on console. env | grep SSH produces SSH_AUTH_SOCK=/tmp/keyring-xxxxx/socket.ssh when both as root or user, and export SSH_AUTH_SOCK= changes the action as before so it requests the passphrase. No idea if anyone knows a workaround as it currently means I have to sudo and then still enter a passphrase for every new terminal tab I open unless I revert to old version of keyring.
Ian, you do not explain how you obtain root on your machine in order to run ssh, but this is not unexpected behavour: either your root user cannot write to your display, or gnome-keyring rejects attempts by root's processes to talk to it, but what is happening is the ssh process as run by root is using the key without using an agent. Running "export SSH_AUTH_SOCK=" removes the environment variable so future ssh processes don't know about the agent which is why you get prompted and the passphrase works: again, ssh is accessing the key without using an agent. For those wanting to just get on, a workaround is to tell your environment to consult a different ssh agent, as follows (making lots of assumptions about your particular environment in order to keep the instructions simple): When you first log in, type "ssh-agent" copy the resulting lines and add them to the bottom of your .bashrc (if you have done this several times, remove previous additions first) close terminal / open a new one (or just type "bash") type "ssh-add" in a new window, type in your passphrase when prompted In my environment (Debian) I get both a gnome-keyring and an ssh-agent process on login, so I adjust my .bashrc so that SSH_AUTH_SOCK points to the socket belonging to the ssh-agent process (which fits the form /tmp/ssh-XXXX/agent.PID rather than /tmp/keyring-xxx...) and SSH_AGENT_PID points to the pid of the ssh-agent process.
I'm currently performing a git bisect to narrow down the changeset which broke this. This is my first git bisect experience. About 16 patches to go.
It's broken at revision 99efefe14cffb2894b83b52dfa889ec574177cba (some commits after 2.25.4.1). I haven't finished bisecting yet, but this revision and a few others provided the following on error console for gnome-session instance: GLib-ERROR **: /tmp/buildd/glib2.0-2.20.1/glib/gmem.c:175: failed to allocate 4294967294 bytes on error console for ssh instance: $ ssh alcopop.org Error reading response length from authentication socket.
$ git bisect bad c21eb1c35df0463b54272da40c04f17de736ab1a is first bad commit commit c21eb1c35df0463b54272da40c04f17de736ab1a Author: Stefan Walter <stefw@src.gnome.org> Date: Thu Jan 8 18:41:26 2009 +0000 Don't try to keep authenticating when bad password on protected auth path * gp11/gp11-module.c: * gp11/gp11-session.c: * gp11/gp11-slot.c: Don't try to keep authenticating when bad password on protected auth path authentication. Protected auth path repeats internally as necessary. * pkcs11/pkcs11g.h: * pkcs11/gck/gck-attributes.c: * pkcs11/gck/gck-object.c: * pkcs11/gck/gck-object.h: * pkcs11/ssh-store/gck-ssh-module.c: * pkcs11/ssh-store/gck-ssh-private-key.c: * pkcs11/ssh-store/gck-ssh-private-key.h: * pkcs11/ssh-store/gck-ssh-public-key.c: * pkcs11/ssh-store/gck-ssh-public-key.h: Added CKA_GNOME_UNIQUE attribute. * daemon/gkr-daemon.c: * daemon/Makefile.am: * daemon/pkcs11/gkr-pkcs11-auth.c: (added) * daemon/pkcs11/gkr-pkcs11-auth.h: (added) * daemon/pkcs11/gkr-pkcs11-auth-ep.c: (added) * daemon/pkcs11/gkr-pkcs11-daemon.c: (added) * daemon/pkcs11/gkr-pkcs11-daemon.h: (added) * daemon/pkcs11/Makefile.am: * daemon/pkix/gkr-pkix-asn1.c: * daemon/ssh/gkr-ssh-daemon.h: (removed) * daemon/ssh/gkr-ssh-daemon-io.c: (removed) * daemon/ssh/gkr-ssh-daemon-ops.c: (removed) * daemon/ssh/Makefile.am: (removed) * daemon/ui/gkr-ask-daemon.c: * pkcs11/ssh-agent/gck-ssh-agent.c: * pkcs11/ssh-agent/gck-ssh-agent-ops.c: Integrate new modular SSH agent as the main gnome-keyring-daemon SSH agent. svn path=/trunk/; revision=1447 :100644 100644 3404b537a8ff2c2e82827a27927523724b9d9618 ce3f13647883f2e8d6355458a3251748b3b93655 M ChangeLog :040000 040000 2086bf66c2d6e53d28ac201cbb22985ff8f4fc6f 353d9fd93d453f468f805ac966689dacb87413fe M daemon :040000 040000 ddc9f295e33323f3f9b95aeae81faae57842edfe df284f1ac34151a25cc4e53cc7c505d70dc4ab49 M gp11 :040000 040000 a849c4b9d9303e7017aeb06cee47d651cc239284 3a4006f5f57143fd41cb1704f1d7d9312dcb6065 M pkcs11 :040000 040000 0d970c3cbf25bc8130539bfb403e34d4d72c9681 c85864668077e7135682bbb3df16daadcfb77e11 M po
This *might* be an architecture issue: https://bugs.launchpad.net/ubuntu/+source/gnome-keyring/+bug/201786 suggests that the only affected people are on amd64 or a big-endian architecture. Both of my affected machines are amd64, my i386 laptop is not. All of the reporters in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=523322 are using amd64 too.
gnome-keyring-daemon actually aborts after an attempt is made to use the SSH key. Here's a gdb backtrace: GLib-ERROR **: /tmp/buildd/glib2.0-2.20.1/glib/gmem.c:175: failed to allocate 4294967294 bytes aborting... Program received signal SIGABRT, Aborted.
+ Trace 215225
Thread 140393051842896 (LWP 20145)
Note that 4294967294 is roughly 4G... I have 2G of memory and strangely, no swap right now. Adding 4G of swap and instead of the realloc failing I get a segfault: Program received signal SIGSEGV, Segmentation fault.
+ Trace 215227
Thread 140470120905040 (LWP 20974)
Oh dear. Ok, I'm afraid the last few traces were probably for a binary built from the bisection (i.e. the commit that introduced the new ssh agent) rather than HEAD. I've just switched back to the main branch and rebuilt. Both traces have gone away (no segfault, no relloc 4G). Trying to use my key (which is RSA and 4119 bytes long, btw) and I get the gnome-keyring prompt: [New Thread 0x7fcc19729950 (LWP 917)] [Thread 0x7fcc19729950 (LWP 917) exited] and then ssh(1) prompts for a password. This is an amd64 machine and the key was generated on this machine. I generated a DSA key and an RSA key on an i386 machine, with passphrases, and then copied them to the amd64 machine. They both work fine...
Also I can confirm the testcase keys attached to this bug do not work (without a passphrase).
Created attachment 134225 [details] RSA key generated on i386 machine private key half of a keypair generated on an i386 machine, works for me on an amd64.
Created attachment 134226 [details] RSA key fingerprint generated on i386 machine public key half of a keypair generated on an i386 machine, works for me on an amd64.
Oh, the passphrase for that demo key is 'password'.
Yesterday I copied a keypair from my amd64 machine that does not work to an i386 machine and it did not work there either. This leads me to think that there is some property of keys generated on amd64 (and other archs perhaps, see 533414) that is not being handled.
I thought I'd mention that I'm seeing the behavior reported in debian bug http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=523322 -- that is that gnome-keyring-daemon is no longer acting as ssh-agent and not creating an ssh-agent socket in /tmp/keyring-xxxxxx, and that I am running on a plain old 32-bit intel system. My keys are several years old and were generated on a 32-bit system. I use exactly the same keys on my laptop, which is running lenny and therefore an older version of gnome-keyring, and I see the desired functionality of gnome-keyring acting as ssh-agent. Hopefully this rules out amd64 as relevant in at least that problem. It's hard for me to see exactly how this bug report is exactly the same as the problem reporting in the debian bug report that is forwarded to this one.
If it helps, I don't actually run much gnome in my environment. I log in using gdm, but that's where it stops. I have a .xsession that opens xterms, emacs, and other non-gnome applications. My window manager is openbox. I don't run any kind of session manager or toolbar. Basically, I am still using my late 1980's desktop that I've had since the dawn of X11. :-) Okay, I have modernized many parts of it, and I do run some gnome applications from time to time. The default gnome Xsession sets up enough things so that dbus et al are working, and I have configured many applications using gconf. But my point is that I'm not running a session manager or anything of the sort. I don't know if that's true of other users who are having this problem.
last comment for now: I'm running debian squeeze which recently got gnome 2.26.
Hi Jay, the reports relating to this bug don't have missing sockets, they just aren't talking properly. I think you are describing a different bug. Do you have the ssh daemon component enabled (gconftool-2 -g /apps/gnome-keyring/daemon-components/ssh)?
Robert Ancell, I can duplicate the problem with the keys you posted, and will look into it. Why is your key 1023 bits? I'm suprised that works at all with OpenSSH.
Fixed this problem. Robert's posted key works now: commit bea17154da4c84f54064489e8ea875b74c7a6256 Author: Stef Walter <stef@memberwebs.com> Date: Fri Jun 26 16:11:49 2009 +0000 Fixed problem with RSA key sizes that were not a multiple of 8. This was a problem in the PKCS#1 padding functions, which calculated the padding length incorrectly. All instances of this have been searched out and fixed. Should fix bug #576700 at least with the key that Robert Ancell posted. This is a rather all encompassing bug report. Please file another bug report for other problems you may encounter. This fix will be included in gnome-keyring 2.26.3 and later versions.
Stef, good news! I'm not sure why the key was 1023 bits, I got these keys from users experiencing this in Ubuntu: https://bugs.launchpad.net/ubuntu/+source/gnome-keyring/+bug/348126
Brilliant news! My key (and I suspect some others) is a funny size because I purposefully added some random jitter to the keysize on creation shortly after the Debian OpenSSL debacle. That way my key was less likely to end up in a pre-computed list of keypairs should another, similar problem be discovered in the future. Thanks for sorting this out!
Interesting. Good idea.
Hi everyone, I just moved from Fedora 9 to Fedora 11 and can confirm this bug with gnome-keyring x86_64 2.26.1-1.fc11 and all the fixes and workarounds here have worked like a charm. I have found another fix too: gnome-keyring-2.26.3-1.fc11.x86_64.rpm is available from the updates-testing repositories for f11 (and I'm sure it can be found for other linux distros) and it seems that the bug is gone (for me at least) with this update. So far, with the exception of google earth not working on 64 bit linux distros (fixable!) I have only encountered two issues, both involving gnome 2.26, both fixed by updates in the updates-testing repositories.