Ubuntu
openssh package

ssh connection hangs after authentication succeeds

Bug #126165 reported by Tim Richardson
2
Affects Status Importance Assigned to Milestone
openssh (Ubuntu)
Invalid
Undecided
Unassigned

Bug Description

From feisty 7.04 ssh -v = OpenSSH_4.3p2 Debian-8ubuntu1, OpenSSL 0.9.8c 05 Sep 2006

when connecting to RedHat
ssh -v = OpenSSH_3.9p1, OpenSSL 0.9.7a Feb 19 2003

the connection hangs after authentication
the ssh -v is attached, but first I point out that I modified /etc/nsswitch like so:
hosts: files dns

im@antec1:/etc$ ssh -vvv <email address hidden>
OpenSSH_4.3p2 Debian-8ubuntu1, OpenSSL 0.9.8c 05 Sep 2006
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to tim-richardson.net [72.34.40.85] port 22.
debug1: Connection established.
debug1: identity file /home/tim/.ssh/identity type -1
debug1: identity file /home/tim/.ssh/id_rsa type -1
debug1: identity file /home/tim/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_3.9p1
debug1: match: OpenSSH_3.9p1 pat OpenSSH_3.*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.3p2 Debian-8ubuntu1
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,<email address hidden>,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,<email address hidden>,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,<email address hidden>,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,<email address hidden>,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,<email address hidden>,zlib
debug2: kex_parse_kexinit: none,<email address hidden>,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,<email address hidden>,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,<email address hidden>,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,<email address hidden>,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,<email address hidden>,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_init: found hmac-md5
debug1: kex: server->client aes128-cbc hmac-md5 none
debug2: mac_init: found hmac-md5
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
debug2: dh_gen_key: priv key bits set: 109/256
debug2: bits set: 532/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug3: check_host_in_hostfile: filename /home/tim/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 1
debug3: check_host_in_hostfile: filename /home/tim/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 1
debug1: Host 'tim-richardson.net' is known and matches the RSA host key.
debug1: Found key in /home/tim/.ssh/known_hosts:1
debug2: bits set: 506/1024
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /home/tim/.ssh/identity ((nil))
debug2: key: /home/tim/.ssh/id_rsa ((nil))
debug2: key: /home/tim/.ssh/id_dsa ((nil))
debug1: Authentications that can continue: publickey,password
debug3: start over, passed a different list publickey,password
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /home/tim/.ssh/identity
debug3: no such identity: /home/tim/.ssh/identity
debug1: Trying private key: /home/tim/.ssh/id_rsa
debug3: no such identity: /home/tim/.ssh/id_rsa
debug1: Trying private key: /home/tim/.ssh/id_dsa
debug3: no such identity: /home/tim/.ssh/id_dsa
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
<email address hidden>'s password:
debug3: packet_send2: adding 48 (len 63 padlen 17 extra_pad 64)
debug2: we sent a password packet, wait for reply
debug1: Authentication succeeded (password).
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug1: Entering interactive session.
debug2: callback start
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 0
debug3: tty_make_modes: ospeed 38400
debug3: tty_make_modes: ispeed 38400
debug3: tty_make_modes: 1 3
debug3: tty_make_modes: 2 28
debug3: tty_make_modes: 3 127
debug3: tty_make_modes: 4 21
debug3: tty_make_modes: 5 4
debug3: tty_make_modes: 6 255
debug3: tty_make_modes: 7 255
debug3: tty_make_modes: 8 17
debug3: tty_make_modes: 9 19
debug3: tty_make_modes: 10 26
debug3: tty_make_modes: 12 18
debug3: tty_make_modes: 13 23
debug3: tty_make_modes: 14 22
debug3: tty_make_modes: 18 15
debug3: tty_make_modes: 30 0
debug3: tty_make_modes: 31 0
debug3: tty_make_modes: 32 0
debug3: tty_make_modes: 33 0
debug3: tty_make_modes: 34 0
debug3: tty_make_modes: 35 0
debug3: tty_make_modes: 36 1
debug3: tty_make_modes: 37 0
debug3: tty_make_modes: 38 1
debug3: tty_make_modes: 39 1
debug3: tty_make_modes: 40 0
debug3: tty_make_modes: 41 1
debug3: tty_make_modes: 50 1
debug3: tty_make_modes: 51 1
debug3: tty_make_modes: 52 0
debug3: tty_make_modes: 53 1
debug3: tty_make_modes: 54 1
debug3: tty_make_modes: 55 1
debug3: tty_make_modes: 56 0
debug3: tty_make_modes: 57 0
debug3: tty_make_modes: 58 0
debug3: tty_make_modes: 59 1
debug3: tty_make_modes: 60 1
debug3: tty_make_modes: 61 1
debug3: tty_make_modes: 62 0
debug3: tty_make_modes: 70 1
debug3: tty_make_modes: 71 0
debug3: tty_make_modes: 72 1
debug3: tty_make_modes: 73 0
debug3: tty_make_modes: 74 0
debug3: tty_make_modes: 75 0
debug3: tty_make_modes: 90 1
debug3: tty_make_modes: 91 1
debug3: tty_make_modes: 92 0
debug3: tty_make_modes: 93 0
debug1: Sending environment.
debug3: Ignored env SSH_AGENT_PID
debug3: Ignored env SHELL
debug3: Ignored env DESKTOP_STARTUP_ID
debug3: Ignored env TERM
debug3: Ignored env GTK_RC_FILES
debug3: Ignored env WINDOWID
debug3: Ignored env USER
debug3: Ignored env LS_COLORS
debug3: Ignored env SSH_AUTH_SOCK
debug3: Ignored env GNOME_KEYRING_SOCKET
debug3: Ignored env SESSION_MANAGER
debug3: Ignored env USERNAME
debug3: Ignored env PATH
debug3: Ignored env DESKTOP_SESSION
debug3: Ignored env GDM_XSERVER_LOCATION
debug3: Ignored env PWD
debug1: Sending env LANG = en_AU.UTF-8
debug2: channel 0: request env confirm 0
debug3: Ignored env GDM_LANG
debug3: Ignored env GDMSESSION
debug3: Ignored env HISTCONTROL
debug3: Ignored env SHLVL
debug3: Ignored env HOME
debug3: Ignored env LANGUAGE
debug3: Ignored env GNOME_DESKTOP_SESSION_ID
debug3: Ignored env LOGNAME
debug3: Ignored env DBUS_SESSION_BUS_ADDRESS
debug3: Ignored env LESSOPEN
debug3: Ignored env DISPLAY
debug3: Ignored env LESSCLOSE
debug3: Ignored env COLORTERM
debug3: Ignored env XAUTHORITY
debug3: Ignored env _
debug3: Ignored env OLDPWD
debug2: channel 0: request shell confirm 0
debug2: fd 3 setting TCP_NODELAY
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768

that is the last message. The terminal hangs. ctrl-c can not interrupt.

See original description
Tim Richardson (tim-richardson)
description: updated
description: updated
Revision history for this message
Soren Hansen (soren) wrote : Re: [Bug 126165] ssh connection hangs after authentication succeeds

On Sun, Jul 15, 2007 at 04:41:52PM -0000, Tim Richardson wrote:
>
> when connecting to RedHat
> ssh -v = OpenSSH_3.9p1, OpenSSL 0.9.7a Feb 19 2003

Does it work from any other OS?

--
Soren Hansen
http://www.ubuntu.com/

Revision history for this message
Tim Richardson (tim-richardson) wrote :

Soren Hansen wrote:
> On Sun, Jul 15, 2007 at 04:41:52PM -0000, Tim Richardson wrote:
>
>> when connecting to RedHat
>> ssh -v = OpenSSH_3.9p1, OpenSSL 0.9.7a Feb 19 2003
>>
>
> Does it work from any other OS?
>
>
 I can connect to that server using Putty under Windows, and via a Java
ssh client.

Revision history for this message
Soren Hansen (soren) wrote :

On Mon, Jul 16, 2007 at 04:34:24AM -0000, Tim Richardson wrote:
> >> when connecting to RedHat ssh -v = OpenSSH_3.9p1, OpenSSL 0.9.7a
> >> Feb 19 2003
> > Does it work from any other OS?
> I can connect to that server using Putty under Windows, and via a Java
> ssh client.

I see. Are they on the same subnet? It sounds rather like a
configuration problem on the server, actually. Are you doing anything
interesting in your .profile (or equivalent for your shell of choice on
the server)?

--
Soren Hansen
Ubuntu Server Team
http://www.ubuntu.com/

Revision history for this message
Tim Richardson (tim-richardson) wrote :

On Mon, 16 Jul 2007 07:03:15 -0000
  Soren Hansen <email address hidden> wrote:
> On Mon, Jul 16, 2007 at 04:34:24AM -0000, Tim Richardson wrote:
>> >> when connecting to RedHat ssh -v = OpenSSH_3.9p1, OpenSSL 0.9.7a
>> >> Feb 19 2003
>> > Does it work from any other OS?
>> I can connect to that server using Putty under Windows, and via a
>>Java
>> ssh client.
>
> I see. Are they on the same subnet? It sounds rather like a
> configuration problem on the server, actually. Are you doing
>anything
> interesting in your .profile (or equivalent for your shell of choice
>on
> the server)?
>
> --
> Soren Hansen
> Ubuntu Server Team
> http://www.ubuntu.com/
>
> --
> ssh connection hangs after authentication succeeds
> https://bugs.launchpad.net/bugs/126165
> You received this bug notification because you are a direct
>subscriber
> of the bug.
 Soren, yes, the java ssh client connects from my Ubuntu desktop (the
machine from which ssh fails). The connection via Putty on Windows
works on the same home network (so via my NAT router, the same
internet IP); I can also connect through a proxy at work using Putty
or the java client).
The remote server is a RedHat machine. The shell is jailshell.
For what it's worth, once I am logged on to the remote server, I can
ssh to the remote server (in effect to local host) with no problems.
So whatever setting problems there may be on the remote server, they
do not cause problems with the older version of openssh-client on the
remote server. It appears that there is an incompatibility between the
two openssh versions. I was able to ssh in on older versions of Ubuntu
... Dapper, for example. How can I help to further identify the
problem?

Revision history for this message
Soren Hansen (soren) wrote :

On Mon, Jul 16, 2007 at 12:15:42PM -0000, Tim Richardson wrote:
> Soren, yes, the java ssh client connects from my Ubuntu desktop (the
> machine from which ssh fails). The connection via Putty on Windows
> works on the same home network (so via my NAT router, the same
> internet IP); I can also connect through a proxy at work using Putty
> or the java client). The remote server is a RedHat machine. The shell
> is jailshell. For what it's worth, once I am logged on to the remote
> server, I can ssh to the remote server (in effect to local host) with
> no problems. So whatever setting problems there may be on the remote
> server, they do not cause problems with the older version of
> openssh-client on the remote server. It appears that there is an
> incompatibility between the two openssh versions. I was able to ssh in
> on older versions of Ubuntu ... Dapper, for example. How can I help to
> further identify the problem?

Could you try prepending 'env -i' to your ssh command line to clear out
the environment? There might be something there that confuses the
server.

--
Soren Hansen
Ubuntu Server Team
http://www.ubuntu.com/

Revision history for this message
Tim Richardson (tim-richardson) wrote :

Soren Hansen wrote:
> On Mon, Jul 16, 2007 at 12:15:42PM -0000, Tim Richardson wrote:
>
>> Soren, yes, the java ssh client connects from my Ubuntu desktop (the
>> machine from which ssh fails). The connection via Putty on Windows
>> works on the same home network (so via my NAT router, the same
>> internet IP); I can also connect through a proxy at work using Putty
>> or the java client). The remote server is a RedHat machine. The shell
>> is jailshell. For what it's worth, once I am logged on to the remote
>> server, I can ssh to the remote server (in effect to local host) with
>> no problems. So whatever setting problems there may be on the remote
>> server, they do not cause problems with the older version of
>> openssh-client on the remote server. It appears that there is an
>> incompatibility between the two openssh versions. I was able to ssh in
>> on older versions of Ubuntu ... Dapper, for example. How can I help to
>> further identify the problem?
>>
>
> Could you try prepending 'env -i' to your ssh command line to clear out
> the environment? There might be something there that confuses the
> server.
>
>
 same end result.
here are the last lines of the debug output.

debug1: Sending environment.
debug2: channel 0: request shell confirm 0
debug2: fd 3 setting TCP_NODELAY
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768

and it hangs again at this point.

Revision history for this message
Soren Hansen (soren) wrote :

On Mon, Jul 16, 2007 at 04:12:36PM -0000, Tim Richardson wrote:
> > Could you try prepending 'env -i' to your ssh command line to clear
> > out the environment? There might be something there that confuses
> > the server.
> same end result. here are the last lines of the debug output.
>
> debug1: Sending environment.
> debug2: channel 0: request shell confirm 0
> debug2: fd 3 setting TCP_NODELAY
> debug2: callback done
> debug2: channel 0: open confirm rwindow 0 rmax 32768
>
> and it hangs again at this point.

I see. The next line I get is about lack of xauth on my server. Could
you try adding -X -A to your ssh command line to disable any attempt to
do X and ssh agent forwarding?

If that doesn't work, is there any chance you could run the server with
debugging enabled, too? Perhaps on a different port so as to not
interefere with your normal operation.

--
Soren Hansen
Ubuntu Server Team
http://www.ubuntu.com/

Revision history for this message
Tim Richardson (tim-richardson) wrote :

This was a bug in my D-Link router firmware. I found an obscure update on the German D-link website. The problem is solved.
Thanks for your efforts, Soren.

Revision history for this message
Micah Cowan (micahcowan) wrote :

Closing bug per reporter's comment.

Changed in openssh:
status: New → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.