Looks like no one’s replied in a while. To start the conversation again, simply ask a new question.

User profile for user: arnab
arnab Author
User level: Level 1
0 points

ssh freezes up on 10.5.2

I have recently started noticing ssh connections freezing up after several minutes of inactivity. I am ssh-ing over the internet from Leopard 10.5.2 to a linux machine behind a firewall, without X forwarding. The connection starts normally and I can work normally for the most part. However if the connection stays idle for several (~10) minutes then the terminal stops responding completely. The terminal application does not stop responding, but the window/tab running the ssh connection stops responding to any keyboard input. My only option seems to be to close the window/tab or let the connection time out after about 20 minutes (remote server setting).

I was wondering if anyone else has seen similar problems (there are several discussion threads about ssh failing completely but none quite like what I am experiencing), and has any idea on how to get around it. I have attached a debug dump of one session below.

Thanks, -A

I start ssh with 3 levels of debugging messages


$ ssh -vvv login
OpenSSH_4.7p1, OpenSSL 0.9.7l 28 Sep 2006
debug1: Reading configuration data /etc/ssh_config
debug2: ssh_connect: needpriv 0
debug1: Connecting to login [xxx.xxx.xxx.xxx] port 22.
debug1: Connection established.
debug1: identity file /Users/arnab/.ssh/identity type -1
debug3: Not a RSA1 key file /Users/arnab/.ssh/id_rsa.
debug2: key type_fromname: unknown key type '-----BEGIN'
debug3: key_read: missing keytype
debug3: key_read: missing whitespace
debug2: key type_fromname: unknown key type '-----END'
debug3: key_read: missing keytype
debug1: identity file /Users/arnab/.ssh/id_rsa type 1
debug1: identity file /Users/arnab/.ssh/id_dsa type -1
debug1: Remote protocol version 1.99, 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.7
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2 MSGKEXINIT sent
debug1: SSH2 MSGKEXINIT received
debug2: kex parsekexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie- hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex parsekexinit: ssh-rsa,ssh-dss
debug2: kex parsekexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes1 92-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex parsekexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes1 92-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex parsekexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.co m,hmac-sha1-96,hmac-md5-96
debug2: kex parsekexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.co m,hmac-sha1-96,hmac-md5-96
debug2: kex parsekexinit: none,zlib@openssh.com,zlib
debug2: kex parsekexinit: none,zlib@openssh.com,zlib
debug2: kex parsekexinit:
debug2: kex parsekexinit:
debug2: kex parsekexinit: first kexfollows 0
debug2: kex parsekexinit: reserved 0
debug2: kex parsekexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-g roup1-sha1
debug2: kex parsekexinit: ssh-rsa,ssh-dss
debug2: kex parsekexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijn dael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex parsekexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijn dael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex parsekexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac- md5-96
debug2: kex parsekexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac- md5-96
debug2: kex parsekexinit: none,zlib
debug2: kex parsekexinit: none,zlib
debug2: kex parsekexinit:
debug2: kex parsekexinit:
debug2: kex parsekexinit: first kexfollows 0
debug2: kex parsekexinit: reserved 0
debug2: mac_setup: found hmac-md5
debug1: kex: server->client aes128-cbc hmac-md5 none
debug2: mac_setup: found hmac-md5
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2 MSG_KEX_DH_GEXREQUEST(1024<1024<8192) sent
debug1: expecting SSH2 MSG_KEX_DH_GEXGROUP
debug2: dh genkey: priv key bits set: 139/256
debug2: bits set: 524/1024
debug1: SSH2 MSG_KEX_DH_GEXINIT sent
debug1: expecting SSH2 MSG_KEX_DH_GEXREPLY
debug3: check host_inhostfile: filename /Users/arnab/.ssh/known_hosts
debug3: check host_inhostfile: match line 1
debug3: check host_inhostfile: filename /Users/arnab/.ssh/known_hosts
debug3: check host_inhostfile: match line 1
debug1: Host 'login' is known and matches the RSA host key.
debug1: Found key in /Users/arnab/.ssh/known_hosts:1
debug2: bits set: 513/1024
debug1: ssh rsaverify: signature correct
debug2: kex derivekeys
debug2: set_newkeys: mode 1
debug1: SSH2 MSGNEWKEYS sent
debug1: expecting SSH2 MSGNEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2 MSGNEWKEYS received
debug1: SSH2 MSG_SERVICEREQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2 MSG_SERVICEACCEPT received
debug2: key: /Users/arnab/.ssh/identity (0x0)
debug2: key: /Users/arnab/.ssh/id_rsa (0x107eb0)
debug2: key: /Users/arnab/.ssh/id_dsa (0x0)
debug3: input userauthbanner

debug1: Authentications that can continue: publickey,gssapi-with-mic,password,hostbased
debug3: start over, passed a different list publickey,gssapi-with-mic,password,hostbased
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod isenabled publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /Users/arnab/.ssh/identity
debug3: no such identity: /Users/arnab/.ssh/identity
debug1: Offering public key: /Users/arnab/.ssh/id_rsa
debug3: send pubkeytest
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 277

debug3: sign and_sendpubkey
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).
debug1: channel 0: new [client-session]
debug3: ssh session2open: channel_new: 0
debug2: channel 0: send open
debug1: Entering interactive session.
debug2: callback start
debug2: client session2setup: id 0
debug2: channel 0: request pty-req confirm 0
debug3: tty makemodes: ospeed 38400
debug3: tty makemodes: ispeed 38400
debug3: tty makemodes: 1 3
debug3: tty makemodes: 2 28
debug3: tty makemodes: 3 127
debug3: tty makemodes: 4 21
debug3: tty makemodes: 5 4
debug3: tty makemodes: 6 255
debug3: tty makemodes: 7 255
debug3: tty makemodes: 8 17
debug3: tty makemodes: 9 19
debug3: tty makemodes: 10 26
debug3: tty makemodes: 11 25
debug3: tty makemodes: 12 18
debug3: tty makemodes: 13 23
debug3: tty makemodes: 14 255
debug3: tty makemodes: 17 255
debug3: tty makemodes: 18 255
debug3: tty makemodes: 30 0
debug3: tty makemodes: 31 0
debug3: tty makemodes: 32 0
debug3: tty makemodes: 33 0
debug3: tty makemodes: 34 0
debug3: tty makemodes: 35 0
debug3: tty makemodes: 36 1
debug3: tty makemodes: 38 1
debug3: tty makemodes: 39 1
debug3: tty makemodes: 40 0
debug3: tty makemodes: 41 1
debug3: tty makemodes: 50 1
debug3: tty makemodes: 51 1
debug3: tty makemodes: 53 1
debug3: tty makemodes: 54 1
debug3: tty makemodes: 55 1
debug3: tty makemodes: 56 0
debug3: tty makemodes: 57 0
debug3: tty makemodes: 58 0
debug3: tty makemodes: 59 1
debug3: tty makemodes: 60 1
debug3: tty makemodes: 61 1
debug3: tty makemodes: 62 1
debug3: tty makemodes: 70 1
debug3: tty makemodes: 72 1
debug3: tty makemodes: 73 0
debug3: tty makemodes: 74 0
debug3: tty makemodes: 75 0
debug3: tty makemodes: 90 1
debug3: tty makemodes: 91 1
debug3: tty makemodes: 92 0
debug3: tty makemodes: 93 0
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
debug2: channel 0: rcvd adjust 131072

At this point I have the connection active. I keep the terminal window open for several minutes in the background, and the terminal becomes non-responsive. Eventually the ssh connection is timed out by the remote machine.


debug1: channel 0: free: client-session, nchannels 1
debug3: channel 0: status: The following connections are open:
#0 client-session (t4 r0 i0/0 o0/0 fd 4/5 cfd -1)

debug3: channel 0: close_fds r 4 w 5 e 6 c -1
Read from remote host login: Operation timed out
Connection to login closed.
debug1: Transferred: stdin 0, stdout 0, stderr 79 bytes in 1691.6 seconds
debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.0
debug1: Exit status -1

Macbook & Mac mini, 10.5.2 and 10.4.11

Posted on Apr 20, 2008 3:25 PM

Reply
4 replies
User profile for user: brunobf
brunobf
User level: Level 1
0 points

May 2, 2008 6:06 AM in response to arnab

Hi,

I'm having the exact same problem as you.
I have a CentOS 5.x server running sshd behind a complex iptables firewall.
I'm using pubkey authentication also.

Whenever I try to login, I get this:

debug2: fd 3 setting TCP_NODELAY
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768

Yeah, hangs right here !


debug1: channel 0: free: client-session, nchannels 1
debug3: channel 0: status: The following connections are open:
#0 client-session (t4 r0 i0/0 o0/0 fd 4/5 cfd -1)

debug3: channel 0: close_fds r 4 w 5 e 6 c -1
Read from remote host xxxxxxx: Operation timed out
Connection to xxxxxxx closed.
debug1: Transferred: stdin 0, stdout 0, stderr 89 bytes in 512.0 seconds
debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.2
debug1: Exit status -1






But strangely, I found a way it doesn't hang, in the same server.
My server has also a PPTP VPN server running, so if I connect to it, and then SSH to the internal VPN address, I get the following:

debug2: fd 3 setting TCP_NODELAY
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768

This is where it was supposed to hang


debug2: channel 0: rcvd adjust 131072
Last login: Fri May 2 09:29:57 2008 from XXXXX
[root@xxxx ~]# logout

At this point the shell was working, so I just logout...


debug2: channel 0: rcvd eof
debug2: channel 0: output open -> drain
debug2: channel 0: obuf empty
debug2: channel 0: close_write
debug2: channel 0: output drain -> closed
debug1: client input_channelreq: channel 0 rtype exit-status reply 0
debug2: channel 0: rcvd close
debug2: channel 0: close_read
debug2: channel 0: input open -> closed
debug3: channel 0: will not send data after close
debug2: channel 0: almost dead
debug2: channel 0: gc: notify user
debug2: channel 0: gc: user detached
debug2: channel 0: send close
debug2: channel 0: is dead
debug2: channel 0: garbage collecting
debug1: channel 0: free: client-session, nchannels 1
debug3: channel 0: status: The following connections are open:
#0 client-session (t4 r0 i3/0 o3/0 fd -1/-1 cfd -1)

debug3: channel 0: close_fds r -1 w -1 e 6 c -1
Connection to xxxxxxxxx closed.
debug1: Transferred: stdin 0, stdout 0, stderr 35 bytes in 7.3 seconds
debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 4.8
debug1: Exit status 0






I am still not sure where the problem is, but I do believe it's related to a firewall/routing issue.
I'm currently behind 3 to 4 private networks before even reaching the internet (yuck, **** hotel).
I read somewhere that it might be related to MTU and fragmentation, but I'm not sure on how I'm gonna figure that out.
Reply
User profile for user: brunobf
brunobf
User level: Level 1
0 points

May 2, 2008 6:22 AM in response to brunobf

I think I found the culprit of our problem.

The original post is on: http://www.securityfocus.com/archive/121/474437/30/300/threaded

OpenSSH sets the IP TOS (to either "lowdelay" or "throughput") and some some routers have been known to choke on such packets.

The TOS is set immediately after the TCP_NODELAY so it's a pretty good bet that's your culprit.

As a workaround, you can recompile ssh then you can insert a "return;" at the start of packet settos() in packet.c. Alternatively you can use ssh's ProxyCommand to use a program such as netcat as an alternative transport that doesn't set those bits, eg:

ssh -o "ProxyCommand nc %h %p" yourserver



Using that command to bypass the TOS actually worked for me.
So now I have to find where the TOS is being chocked.

cheers
Reply

ssh freezes up on 10.5.2

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple ID.
Learn more Sign up