http://bugzilla.mindrot.org/show_bug.cgi?id=538
Summary: Hanging while connecting
Product: Portable OpenSSH
Version: 3.6p1
Platform: ix86
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: ssh
AssignedTo: openssh-unix-dev at mindrot.org
ReportedBy: ao at infinet.com
I'm running into the following problem continually. I'm unsure if its
the ssh on
the client side or the sshd on the server side, but here's what happens
(with -v
output):
OpenSSH_3.4p1, SSH protocols 1.5/2.0, OpenSSL 0x0090603f
debug1: Reading configuration data /usr/local/etc/ssh_config
debug1: Rhosts Authentication disabled, originating port will not be trusted.
debug1: ssh_connect: needpriv 0
debug1: Connecting to ******** [***.***.***.***] port 22.
debug1: Connection established.
debug1: identity file /home/********/.ssh/identity type -1
debug1: identity file /home/********/.ssh/id_rsa type -1
debug1: identity file /home/********/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_3.4p1
Debian 1:3.4p1-1
debug1: match: OpenSSH_3.4p1 Debian 1:3.4p1-1 pat OpenSSH*
Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.4p1
debug1: SSH2_MSG_KEXINIT sent
Hangs here forever, or is OK and...
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 zlib
debug1: kex: client->server aes128-cbc hmac-md5 zlib
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: dh_gen_key: priv key bits set: 124/256
debug1: bits set: 1577/3191
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'alex' is known and matches the RSA host key.
debug1: Found key in /home/miko/.ssh/known_hosts:8
debug1: bits set: 1570/3191
debug1: ssh_rsa_verify: signature correct
debug1: kex_derive_keys
debug1: newkeys: mode 1
debug1: Enabling compression at level 6.
debug1: SSH2_MSG_NEWKEYS sent
debug1: waiting for SSH2_MSG_NEWKEYS
debug1: newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: done: ssh_kex2.
debug1: send SSH2_MSG_SERVICE_REQUEST
hangs forever here instead.
If I am lucky, about 1 in 30 connection attempts actually succeed.
Does anyone have any idea what this problem might be?
Thanks,
Mike Harrold
Email: mharrold(!!at!!)cas.org
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugzilla.mindrot.org/show_bug.cgi?id=538 ------- Additional Comments From dtucker at zip.com.au 2003-04-08 09:02 ------- Is there a firewall, packet filter or NAT device between client and server? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
http://bugzilla.mindrot.org/show_bug.cgi?id=538 ------- Additional Comments From djm at mindrot.org 2003-04-09 13:23 ------- Does the hostname that you are trying to connect to resolve to multiple addresses? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
http://bugzilla.mindrot.org/show_bug.cgi?id=538
onu at 29.ca changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |onu at 29.ca
Platform|ix86 |UltraSparc
------- Additional Comments From onu at 29.ca 2003-04-14 14:45 -------
I am experiencing the same problem.
First, the answer to both the questions of Darren and Damien is no.
My SSH server is a Sun Ultra 5 running Debian. The choice of client machine
seems irrelavant. Connections using protocol 1 seem much less likely to hang.
The problem occurs both with the Ultra 5's built-in network interface as
well
as a 3Com network card I installed to diagnose this problem. Connecting
through the loopback network interface on the server, the connection is
successful.
The connection seems to hang in different places, for example:
(client) debug1: SSH2_MSG_KEXINIT sent
(server) debug1: kex: server->client aes128-cbc hmac-md5 none~.
debug3: preauth child monitor started
debug3: mm_request_receive entering
or
(client) debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
(server) debug1: expecting SSH2_MSG_NEWKEYS
Please let me know if you would like me to provide any additional information.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugzilla.mindrot.org/show_bug.cgi?id=538 ------- Additional Comments From dtucker at zip.com.au 2003-04-14 17:55 ------- Does the server use ssh-rand-helper? Linuxes normally have a /dev/[u]random device. Does the server have any iptables/ipchains rules? It may be DNS reverse-resoultion, you can try starting sshd with -u0 to prevent DNS lookups. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
http://bugzilla.mindrot.org/show_bug.cgi?id=538 ------- Additional Comments From onu at 29.ca 2003-04-16 11:01 ------- Though it's not entirely clear whether /dev/randon or /dev/urandom is used (see http://article.gmane.org/gmane.linux.debian.ports.sparc/3037), it does seem that ssh-rand-helper isn't involved. iptables is not part of the equation either: Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination I tried running sshd with -u0, but I didn't find the number of hung connections changed much. What continues to puzzle me is that connections from the server to itself (ie. ssh localhost) never fail. Nonetheless, changing network cards didn't help. I wonder if some other hardware component might be faulty. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
http://bugzilla.mindrot.org/show_bug.cgi?id=538 ------- Additional Comments From dtucker at zip.com.au 2003-04-16 15:48 ------- If it works fine on localhost then it really does sound like an MTU problem, although you don't seem to have any of the usual suspects for that (eg NAT). Humour me and set your network interface's MTU to 576 (make a note of the current settings then run "ifconfig eth0 mtu 576") and retest. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
http://bugzilla.mindrot.org/show_bug.cgi?id=538 ------- Additional Comments From onu at 29.ca 2003-04-20 09:58 ------- With an MTU setting of 576, connections would still hang, but noticeably less often. Encouraged by this, I set the MTU to 200. With this MTU, I haven't experienced a single hung session. I've tried two different network cards, one switch and one hub and in all cases, only with an MTU of 200 can I avoid hung sessions. I still don't understand whether this is a software or a hardware problem. I'll probably leave the MTU to 200 for now. In a month or two, I expect to have a second identical Ultra 5. Maybe it will help diagnose the problem. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
http://bugzilla.mindrot.org/show_bug.cgi?id=538 ------- Additional Comments From tim at multitalents.net 2003-04-20 12:09 ------- Could your Ultra 5 be connected to a Cisco hub/switch? Some Sun hardware is notorious for getting into negotiation loops with the switch on network parameters. Ie. 10/100, Half/Full duplex. The solution is to lock down at least one side with the parameters you want. It may not be your problem but it's worth a try. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.