edgy - ssh client freeze

Could you please run ssh with the -v option. This will tell you at what point the client is hanging.

Below is sample output

doza@grzmot:~$ ssh -v <email address hidden>
OpenSSH_4.3p2 Debian-4ubuntu1, OpenSSL 0.9.8b 04 May 2006
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to juliusz.mat.umk.pl [158.75.2.230] port 22.
debug1: Connection established.
debug1: identity file /home/doza/.ssh/identity type -1
debug1: identity file /home/doza/.ssh/id_rsa type -1
debug1: identity file /home/doza/.ssh/id_dsa type 2
debug1: Remote protocol version 1.99, remote software version OpenSSH_4.0
debug1: match: OpenSSH_4.0 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.3p2 Debian-4ubuntu1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'juliusz.mat.umk.pl' is known and matches the RSA host key.
debug1: Found key in /home/doza/.ssh/known_hosts:3
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received

I am sorry, false alarm - it seems to work now also from gnome-terminal. It was probably some issue with my configuration. You may close this bug.

I am experiencing the same behavior

(jasonr@luso:~)% ssh -v localhost (23:13)
OpenSSH_4.3p2 Debian-4ubuntu1, OpenSSL 0.9.8b 04 May 2006
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to localhost [127.0.0.1] port 22.
debug1: Connection established.
debug1: identity file /home/jasonr/.ssh/identity type -1
debug1: identity file /home/jasonr/.ssh/id_rsa type -1
debug1: identity file /home/jasonr/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3p2 Debian-4ubuntu1
debug1: match: OpenSSH_4.3p2 Debian-4ubuntu1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.3p2 Debian-4ubuntu1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'localhost' is known and matches the RSA host key.
debug1: Found key in /home/jasonr/.ssh/known_hosts:12
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received

I agree with you it is some kind of configuration issue. Using the same user on tty1 works fine and other users on my system can ssh as this problem user just fine. Do you have any ideas what the issue could be? Thanks.

Ok this is pretty strange, and I don't really understand what is happening. I had rebooted to see if it would resolve itslef but the problem persisted. Then I tried to log out of gnome but it was hanging so I killed all my user's processes. When I logged into GNOME again the problem was resolved and the ssh client was working fine again.

I have this problem AGAIN, no idea why and why it was not happening for some time.
With other terminals under X, like xterm it's the same.

I think I caused the problem by adding ssh-agent into GNOME session. Without it it's all OK

I am experiencing the same problem after an upgrade from dapper to edgy. I do NOT, however, have ssh-agent in my gnome session. Additional testing revealed that the ssh-agent process is being launched via Xsession (/etc/X11/Xsession.options). It locks up so hard that it can not even be killed but becomes a zombie.

Starting another ssh-agent in a terminal later on and using that one (after having updated the environment) is no problem at all.
This is a somewhat mysterious and annoying issue. If anyone has a solution please add it here.

Somebody mentioned on IRC that this could be due to running both ssh-agent and seahorse-daemon. I'm not familiar with seahorse ...

Yes, ssh was hanging again for me again so I tried to kill
seahorse-agent and seahorse-daemon and then ssh worked. So that at
least narrows down the problem.

I also have this problem. This bug is the first sensible discussion of the issue I have found all day. I've actually been able to do something using the tty1, thanks for that tip!

I am using gnupg with enigmail for thunderbird. In the course of working with it, I've installed several key agents of one kind or another. I am using edgy with gnome. I can see a few things:

Applications -> System Tools -> GnomePGP (0.4)
Applications -> Accessories -> Encryption Keys (alias for seahorse 0.9.5)
Applications -> Accessories -> GNU Privacy Assistant (0.7.0)

System -> Preferences -> Encryption Preferences
This fails to start! When I try to start this, there is an app icon in the lower gnome panel with the title "Starting Encryption Preferences" and it disappears with the application launching properly. While this happens, a 'top' indicates a brief appearance of "seahorse-prefer". At the root prompt, we get:

root@dnlweber:/home/dweber# seahorse-preferences

(seahorse-preferences:29644): GnomeUI-WARNING **: While connecting to session manager:
Authentication Rejected, reason : None of the authentication protocols specified are supported and host-based authentication failed.

That might be expected after an 'su' within my user gnome-terminal session. If the same app is run as a normal user, within that user gnome-session, it just hangs with no errors or warnings at all. This looks a lot like the hang we get from ssh - no warnings or errors, just hung indefinitely.

$ apt-cache search seahorse
gpgp - gnome front-end to GnuPG - a free PGP replacement
seahorse - A Gnome front end for GnuPG

Are these packages the same thing? Do they conflict? It seems that only seahorse picks up the .ssh/ keys when it gets started from:

Applications -> Accessories -> Encryption Keys (alias for seahorse 0.9.5)

The other gnupgp programs only pickup the GnuPGP keys, they don't touch the ssh keys.

I purged seahorse. At this point, I need to post this, logout and then see if ssh will work within gnome-session/terminal. It works fine in tty1, with or without seahorse.

I have been hit by this bug today as well. For some reason, seahorse doesn't seem to respond to the auth socket. seahorse-preferences claims there was no ssh agent running. I didn't find out what went wrong in seahorse.

Reassigning to seahorse therefore, openssh is not at fault here.

This bug is related to #105818 and #91116.

Here's the fix that worked for me:

Preface: Seahorse does not work with gpg-agent (see http://live.gnome.org/Seahorse/SessionIntegration).

The behavior that I observed is exactly the same as what others have mentioned in this ticket and in #105818. Seahorse provides ssh-agent functionality for one authentication, then it dies, hence the "[seahorse-agent] <defunct>". I took a guess that maybe Seahorse was dying on my machine because I also had gnupg-agent installed, as I was using it in 6.06 before upgrading to Feisty.

Removing gnupg-agent (don't worry, Seahorse provides equivalent functionality) and logging out and logging back in corrected the issues for me.

I'm interested in hearing whether this fixes the issue for other people.

[Expired for seahorse (Ubuntu) because there has been no activity for 60 days.]

"You will find this is due to SSH not being able to map your IP to name as is normally caused by a non responding DNS server in /etc/resolv.conf. As such if you update this with one that work you should find it suddenly comes to (life)."