I'm booting up to F18 and then trying to ssh to a remote server where I have key-based authentication configured. My keyring is unlocked and `ssh-add -l` shows the proper key as available. However, when I attempt to connect, the connection hangs indefinitely. 'ssh -v' reveals: debug1: Next authentication method: publickey debug1: Offering RSA public key: /home/mattdm/.ssh/id_rsa debug1: Server accepts key: pkalg ssh-rsa blen 535 at which point it just sits there. If I unset SSH_AUTH_SOCK and try again, I'm prompted for my key passphrase, and after I provide it, the connection proceeds successfully. gnome-keyring-3.6.2-2.fc18.x86_64 openssh-clients-6.1p1-4.fc18.x86_64 (And on the remote system, openssh-server-5.3p1-81.el6.x86_64
I am having exactly the same problem in Fedora 17. With ssh -vvv, the connection hangs after: debug3: sign_and_send_pubkey: RSA [xx:xx:...] Observed this on the same remote system SSH version as the original reporter, as well as other versions and distributions. Nothing appears in /var/log/audit/audit.log. I used to be able to fix this by rebooting, and it seemed for a while that it appeared only after a kernel update. However, a reboot no longer fixes the problem. Any suggestions for tracking down the root cause?
Bug 821066 appears to be the same issue, although the reporter stopped seeing the problem and closed that bug.
Some questions for diagnosing: * What is the $SSH_AUTH_SOCK environment variable set to? * Once this hang occurs is gnome-keyring-daemon using a lot of CPU? That is, does it look like it's hung in a loop? * Could you get a backtrace of the gnome-keyring-daemon process? http://fedoraproject.org/wiki/StackTraces
I too see this behaviour trying to ssh with a key. If I kill and restart gnome-keyring (as described in bug 821066) I can ssh fine. $ echo $SSH_AUTH_SOCK /run/user/1000/keyring-5OCEUd/ssh While the ssh client is "stuck" top shows that gnome-keyring-daemon is idling: 1746 james 20 0 1115m 11m 3384 S 0.0 0.3 0:00.45 gnome-keyring-d And, without any debuginfo installed, the bt from attaching to gnome-keyring-daemon: (gdb) bt #0 0x0000003d934e998d in poll () from /lib64/libc.so.6 #1 0x0000003d93047d44 in g_main_context_iterate.isra.24 () from /lib64/libglib-2.0.so.0 #2 0x0000003d930481a2 in g_main_loop_run () from /lib64/libglib-2.0.so.0 #3 0x000000000040f9a8 in main ()
Forgot the info threads output: (gdb) info threads Id Target Id Frame 15 Thread 0x7f70eaec9700 (LWP 1747) "gnome-keyring-d" 0x0000003d93c0ed90 in sigwait () from /lib64/libpthread.so.0 14 Thread 0x7f70ea6c8700 (LWP 1748) "timer" 0x0000003d93c0b5e5 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 13 Thread 0x7f70e9a7a700 (LWP 1749) "dconf worker" 0x0000003d934e998d in poll () from /lib64/libc.so.6 12 Thread 0x7f70e9279700 (LWP 1750) "gdbus" 0x0000003d934e998d in poll () from /lib64/libc.so.6 11 Thread 0x7f70e8a78700 (LWP 1980) "pool" 0x0000003d934e998d in poll () from /lib64/libc.so.6 10 Thread 0x7f70dbfff700 (LWP 2050) "dispatch" 0x0000003d93c0e12d in read () from /lib64/libpthread.so.0 9 Thread 0x7f70db7fe700 (LWP 2055) "dispatch" 0x0000003d93c0e12d in read () from /lib64/libpthread.so.0 8 Thread 0x7f70daffd700 (LWP 2089) "dispatch" 0x0000003d93c0e12d in read () from /lib64/libpthread.so.0 7 Thread 0x7f70da7fc700 (LWP 2306) "ssh-agent" 0x0000003d934e998d in poll () from /lib64/libc.so.6 6 Thread 0x7f70d97fa700 (LWP 2358) "dispatch" 0x0000003d934e998d in poll () from /lib64/libc.so.6 5 Thread 0x7f70d8ff9700 (LWP 2360) "dispatch" 0x0000003d934e998d in poll () from /lib64/libc.so.6 4 Thread 0x7f70c3fff700 (LWP 2361) "dispatch" 0x0000003d934e998d in poll () from /lib64/libc.so.6 3 Thread 0x7f70d9ffb700 (LWP 4834) "ssh-agent" 0x0000003d934e998d in poll () from /lib64/libc.so.6 2 Thread 0x7f70c2ffd700 (LWP 6122) "ssh-agent" 0x0000003d934e998d in poll () from /lib64/libc.so.6 * 1 Thread 0x7f70f12ba800 (LWP 1746) "gnome-keyring-d" 0x0000003d934e998d in poll () from /lib64/libc.so.6
Thanks for the info. That has ruled out several possibilities. Would it be possible to send me an 'ssh -vvv ...' output log? I realize it may contain sensitive data (such has host or file names). You might choose to purge it, post it here, or send it to me depending on your privacy requirements.
Debug log sent directly to Stef.
Just got a bunch of updates and now it seems to work.
Happy that it works now. I believe this was fixed with bug #907156. *** This bug has been marked as a duplicate of bug 907156 ***
Not relevant to Fedora or this bug report itself, but thought I'd give a general digression on the same topic to others who may have landed here through Google or other search engines: After running the same setup using Ubuntu 12.10, gnome-keyring 3.6.1-0ubuntu1.1 plus tmux for months I experienced a similar behaviour for the first time today. Playing around with ~/.ssh/config did not seem to resolve anything, but after closing and opening a new window the failure was resolved for reasons unknown. Lessons learned; if you experienced something similar try to open a new shell first. There may not be anything wrong with your config or internet connection.
FWIW: Just experienced this issue on FC20. ssh was again hung after debug3: sign_and_send_pubkey: RSA and was blocked on unix_stream_recvmsg(). $ sudo kill -9 `pidof gnome-keyring-daemon` corrected the issue. Next time I'll try to get a coredump.
Like Tim Sæterøy, I ran into this too and wanted to give a pointer to others that land here through a search engine. (Currently this bug is the top link if you search for "ssh hangs after sign_and_send_pubkey".) Basically, I forgot that I'd recently changed my .zshrc to not start ssh-agent, or not source the file it stores $SSH_AUTH_SOCK in. So I fixed my usage of ssh-agent and everything was fine after that. This may or may not have anything to do or any impact on gnome-keyring (the topic of this bug). To be honest I'm not sure if I use it or not. But I don't think so.
I'd like to mention that this is a distinct possibility: For example I have just encountered this issue. Here's what the problem is. I am SSHing from one OS X machine to another OS X machine in order to SSH (again) into Ubuntu running in a VM on the second OS X machine. At the *second* hop, this ssh connection totally hangs after sign_and_send_pubkey. What's happening is that OS X has some special handling for (what is apparently) filesystem access to your ~/.ssh/id_rsa. So we think that it hangs but the dialog box asking for your password is being shown in the windowmanager. I would not be surprised if something very similar to this also can happen on a linux environment, and it will manifest only if you happen to have a window manager session ongoing... Like others have mentioned, it was upon applying the fix (Just run SSH_AUTH_SOCK= on your shell) it became obvious this is what's happening.