I want to ssh to a RedHat server running OpenSSH_3.9p1, OpenSSL 0.9.7a
Feb 19 2003
The server hosts several websites.

I have used three machines all from behind the same NAT
1) Debian unstable 4.6p1 OpenSSL 0.9.8e
2) Ubuntu 7.04: ssh -v = OpenSSH_4.3p2 Debian-8ubuntu1, OpenSSL 0.9.8c
05 Sep 2006
3) Mac OS X

The error log is below. The session hangs. Ctrl-C does not recover, I
have to kill the terminal window.

Note that a Windows machine running Putty succeeds, and on all three
machines above, a Java ssh client succeeds.

The problem exists on two accounts on the server.

using env -i ssh ... makes no difference to the result.


the connection hangs after authentication
the ssh -v is attached

The log file is very similar for all three configurations.
I can't get any effective from the Ubuntu or the Debian
communities.


im@antec1:/etc$ ssh -vvv timrich@tim-richardson.net
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,rijndael-
cbc@lysator.liu.se,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,rijndael-
cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-
ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-
ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: none,zlib@openssh.com,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,rijndael-cbc@lysator.liu.se,aes128-
ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-
cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-
ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-
ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-
ripemd160@openssh.com,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
timrich@tim-richardson.net'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.

> the connection hangs after authentication
> the ssh -v is attached

I've been getting that same hang after "debug2: channel 0: open confirm
rwindow 0 rmax 32768" for a few weeks now. (I rarely ssh out from this
particular machine, so it's hard to tell exactly when it stopped
working. For completeness, I'll mention that process occasionally hangs
right after "debug1: identity file /root/.ssh/id_dsa type -1". Not sure
why, but let's consider that secondary.)

I'm using OpenSSH on a 2.6.7 kernel:

OpenSSH_3.8.1p1 Debian-8.sarge.2, OpenSSL 0.9.7d 17 Mar 2004.

This machine used to work just fine, and I'm not aware of having changed
anything with it. In a lab with a *bunch* of machines, I haven't yet
found one that I am able to ssh into, so the problem seems to be pervasive.

I saw a post where somebody was speculating that there might be a DNS
resolution problem right after authentication, but the issue persists
even when I specify the target machine by IP address.

> The terminal hangs. ctrl-c can not interrupt.

Same thing here. I have to kill the process.

> the connection hangs after authentication
> the ssh -v is attached

I've been getting that same hang after "debug2: channel 0: open confirm
rwindow 0 rmax 32768" for a few weeks now. (I rarely ssh out from this
particular machine, so it's hard to tell exactly when it stopped
working. For completeness, I'll mention that process occasionally hangs
right after "debug1: identity file /root/.ssh/id_dsa type -1". Not sure
why, but let's consider that secondary.)

I'm using OpenSSH on a 2.6.7 kernel:

OpenSSH_3.8.1p1 Debian-8.sarge.2, OpenSSL 0.9.7d 17 Mar 2004.

This machine used to work just fine, and I'm not aware of having changed
anything with it. In a lab with a *bunch* of machines, I haven't yet
found one that I am able to ssh into, so the problem seems to be pervasive.

I saw a post where somebody was speculating that there might be a DNS
resolution problem right after authentication, but the issue persists
even when I specify the target machine by IP address.

> The terminal hangs. ctrl-c can not interrupt.

Same thing here. I have to kill the process.

On Jul 18, 7:17 pm, Neil Steiner <neil.stei...@vt.edu> wrote:
> > the connection hangs after authentication
> > the ssh -v is attached
>
> I've been getting that same hang after "debug2: channel 0: open confirm
> rwindow 0 rmax 32768" for a few weeks now. (I rarely ssh out from this
> particular machine, so it's hard to tell exactly when it stopped
> working. For completeness, I'll mention that process occasionally hangs
> right after "debug1: identity file /root/.ssh/id_dsa type -1". Not sure
> why, but let's consider that secondary.)
>
> I'm using OpenSSH on a 2.6.7 kernel:
>
> OpenSSH_3.8.1p1 Debian-8.sarge.2, OpenSSL 0.9.7d 17 Mar 2004.
>
> This machine used to work just fine, and I'm not aware of having changed
> anything with it. In a lab with a *bunch* of machines, I haven't yet
> found one that I am able to ssh into, so the problem seems to be pervasive.
>
> I saw a post where somebody was speculating that there might be a DNS
> resolution problem right after authentication, but the issue persists
> even when I specify the target machine by IP address.
>
> > The terminal hangs. ctrl-c can not interrupt.
>
> Same thing here. I have to kill the process.

For me, I can also reproduce the problem in reverse. I set up sshd on
a debian box at home and set up the firewall.
>From the same Debian box, I used the Java ssh client to log on to my
webhoste (Redhat). I tried ssh -vvv back to my home computer. The log
file showed exactly the same problem. My password was accepted, and
then the session hangs, with exactly the same final message from the
log file.

Since the problem affects three home machines all running different
versions of openssh, it is not machine specific.
I wonder now about my router, a D-LINK. But since ssh works when using
non openssh clients, I still think this can be called a bug in openssh.

> For me, I can also reproduce the problem in reverse. I set up sshd on
> a debian box at home and set up the firewall.
>>From the same Debian box, I used the Java ssh client to log on to my
> webhoste (Redhat). I tried ssh -vvv back to my home computer. The log
> file showed exactly the same problem. My password was accepted, and
> then the session hangs, with exactly the same final message from the
> log file.
>
> Since the problem affects three home machines all running different
> versions of openssh, it is not machine specific.
> I wonder now about my router, a D-LINK. But since ssh works when using
> non openssh clients, I still think this can be called a bug in openssh.

I'm getting this problem with two machines that are plugged into the
same hub, and no firewalling as far as I know. There's certainly no
router involved.

On Jul 19, 7:28 pm, Neil Steiner <neil.stei...@vt.edu> wrote:
> > For me, I can also reproduce the problem in reverse. I set up sshd on
> > a debian box at home and set up the firewall.
> >>From the same Debian box, I used the Java ssh client to log on to my
> > webhoste (Redhat). I tried ssh -vvv back to my home computer. The log
> > file showed exactly the same problem. My password was accepted, and
> > then the session hangs, with exactly the same final message from the
> > log file.
>
> > Since the problem affects three home machines all running different
> > versions of openssh, it is not machine specific.
> > I wonder now about my router, a D-LINK. But since ssh works when using
> > non openssh clients, I still think this can be called a bug in openssh.
>
> I'm getting this problem with two machines that are plugged into the
> same hub, and no firewalling as far as I know. There's certainly no
> router involved.

I found an update to my router firmware on the German site of D-Link.
It was a major update; with much new functionality and a complete
upgrade of the user-interface. The openssh problem has gone. I also
had problems with IPv6 when the router was acting as the DNS server
passed to DHCP clients, and I would not be surprised to find they have
gone as well.
To others, my router is a DSL-564T and the new firmware is dated
20060831