After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 576700 - SSH key not working via gnome-keyring / gnome-terminal
SSH key not working via gnome-keyring / gnome-terminal
Status: RESOLVED FIXED
Product: gnome-keyring
Classification: Core
Component: general
2.26.x
Other All
: Normal major
: ---
Assigned To: GNOME keyring maintainer(s)
GNOME keyring maintainer(s)
: 577842 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2009-03-25 11:05 UTC by Ian
Modified: 2009-07-16 17:22 UTC
See Also:
GNOME target: ---
GNOME version: 2.25/2.26


Attachments
ssh -vvv output via gnome-terminal custom command (6.53 KB, text/plain)
2009-03-25 11:09 UTC, Ian
Details
Private key for test case (883 bytes, text/plain)
2009-04-29 07:11 UTC, Robert Ancell
Details
Public key for test case (224 bytes, text/plain)
2009-04-29 07:12 UTC, Robert Ancell
Details
RSA key generated on i386 machine (1.70 KB, text/plain)
2009-05-07 21:42 UTC, Jon Dowland
Details
RSA key fingerprint generated on i386 machine (394 bytes, text/plain)
2009-05-07 21:43 UTC, Jon Dowland
Details

Description Ian 2009-03-25 11:05:01 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.
Comment 1 Ian 2009-03-25 11:09:43 UTC
Created attachment 131336 [details]
ssh -vvv output via gnome-terminal custom command
Comment 2 Stef Walter 2009-04-02 04:02:06 UTC
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.

Comment 3 Ian 2009-04-02 12:46:35 UTC
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.
Comment 4 Stef Walter 2009-04-11 16:21:09 UTC
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.
Comment 5 Ian 2009-04-14 10:04:31 UTC
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
Comment 6 Jon Dowland 2009-04-21 17:24:59 UTC
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.
Comment 7 Jon Dowland 2009-04-21 18:29:12 UTC
ok, confirmed on my desktop computer. Now to try 2.26.1.
Comment 8 Jon Dowland 2009-04-21 19:00:45 UTC
Yup still happens with 2.26.1. 
Comment 9 Jon Dowland 2009-04-21 20:13:16 UTC
[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.
Comment 10 Robert Ancell 2009-04-29 07:10:52 UTC
*** Bug 577842 has been marked as a duplicate of this bug. ***
Comment 11 Robert Ancell 2009-04-29 07:11:42 UTC
Created attachment 133541 [details]
Private key for test case
Comment 12 Robert Ancell 2009-04-29 07:12:14 UTC
Created attachment 133542 [details]
Public key for test case
Comment 13 Robert Ancell 2009-04-29 07:17:12 UTC
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)
Comment 14 Robert Ancell 2009-04-29 07:23:15 UTC
Tested on Ubuntu 9.04 with:
gnome-keyring 2.26.1
openssh 5.1p1
seahorse 2.26.1
Comment 15 Ian 2009-05-06 16:30:58 UTC
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. 
Comment 16 Jon Dowland 2009-05-06 18:07:34 UTC
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.
Comment 17 Jon Dowland 2009-05-07 18:24:10 UTC
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.
Comment 18 Jon Dowland 2009-05-07 18:27:50 UTC
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.
Comment 19 Jon Dowland 2009-05-07 18:36:01 UTC
$ 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
Comment 20 Jon Dowland 2009-05-07 20:02:25 UTC
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. 
Comment 21 Jon Dowland 2009-05-07 20:34:24 UTC
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.

Thread 140393051842896 (LWP 20145)

  • #0 raise
    from /lib/libc.so.6
  • #1 abort
    from /lib/libc.so.6
  • #2 g_logv
    from /usr/lib/libglib-2.0.so.0
  • #3 g_log
    from /usr/lib/libglib-2.0.so.0
  • #4 g_realloc
    from /usr/lib/libglib-2.0.so.0
  • #5 attribute_init
    at gp11-attributes.c line 45
  • #6 initialize_from_valist
    at gp11-attributes.c line 748
  • #7 gp11_module_enumerate_objects
    at gp11-module.c line 985
  • #8 op_request_identities
    at gck-ssh-agent-ops.c line 659
  • #9 run_client_thread
    at gck-ssh-agent.c line 164
  • #10 ??
    from /usr/lib/libglib-2.0.so.0
  • #11 start_thread
    from /lib/libpthread.so.0
  • #12 clone
    from /lib/libc.so.6
  • #13 ??

Comment 22 Jon Dowland 2009-05-07 20:49:02 UTC
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.

Thread 140470120905040 (LWP 20974)

  • #0 memcpy
    from /lib/libc.so.6
  • #1 initialize_from_valist
    at gp11-attributes.c line 748
  • #2 gp11_module_enumerate_objects
    at gp11-module.c line 985
  • #3 op_request_identities
    at gck-ssh-agent-ops.c line 659
  • #4 run_client_thread
    at gck-ssh-agent.c line 164
  • #5 g_thread_create_proxy
    at /tmp/cdt.XX50MgKl/build-area/glib2.0-2.20.1/glib/gthread.c line 635
  • #6 start_thread
    from /lib/libpthread.so.0
  • #7 clone
    from /lib/libc.so.6
  • #8 ??

Comment 23 Jon Dowland 2009-05-07 21:02:44 UTC
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...
Comment 24 Jon Dowland 2009-05-07 21:07:32 UTC
Also I can confirm the testcase keys attached to this bug do not work (without a passphrase).
Comment 25 Jon Dowland 2009-05-07 21:42:54 UTC
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.
Comment 26 Jon Dowland 2009-05-07 21:43:48 UTC
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.
Comment 27 Jon Dowland 2009-05-07 21:57:04 UTC
Oh, the passphrase for that demo key is 'password'.
Comment 28 Jon Dowland 2009-05-09 07:42:55 UTC
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.
Comment 29 Jay Berkenbilt 2009-05-22 01:38:21 UTC
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.
Comment 30 Jay Berkenbilt 2009-05-22 01:43:48 UTC
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.
Comment 31 Jay Berkenbilt 2009-05-22 01:44:43 UTC
last comment for now: I'm running debian squeeze which recently got gnome 2.26.
Comment 32 Jon Dowland 2009-05-22 10:27:20 UTC
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)?
Comment 33 Stef Walter 2009-06-26 15:25:37 UTC
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. 
Comment 34 Stef Walter 2009-06-26 16:15:57 UTC
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.
Comment 35 Robert Ancell 2009-06-27 04:40:56 UTC
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
Comment 36 Jon Dowland 2009-06-29 17:02:06 UTC
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!
Comment 37 Stef Walter 2009-06-29 17:16:55 UTC
Interesting. Good idea.
Comment 38 Kevin 2009-07-16 17:22:26 UTC
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.