12

I can ssh to server in my house, but I fail to ssh by some VPN or public wifi(not all). when I type ssh -v user@server.domain, I got this:

OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011
debug1: Reading configuration data /etc/ssh_config
debug1: /etc/ssh_config line 20: Applying options for *
debug1: /etc/ssh_config line 102: Applying options for *
debug1: Connecting to server.domain [server.ip.address] port 22.
debug1: Connection established.
debug1: identity file /Users/Hung/.ssh/id_rsa type 1
debug1: identity file /Users/Hung/.ssh/id_rsa-cert type -1
debug1: identity file /Users/Hung/.ssh/id_dsa type -1
debug1: identity file /Users/Hung/.ssh/id_dsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.2

and then, no response for as long as it can be. anybody could help? the following is normal one:

OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011
debug1: Reading configuration data /etc/ssh_config
debug1: /etc/ssh_config line 20: Applying options for *
debug1: /etc/ssh_config line 102: Applying options for *
debug1: Connecting to server.domain [server.ip.address] port 22.
debug1: Connection established.
debug1: identity file /Users/Hung/.ssh/id_rsa type 1
debug1: identity file /Users/Hung/.ssh/id_rsa-cert type -1
debug1: identity file /Users/Hung/.ssh/id_dsa type -1
debug1: identity file /Users/Hung/.ssh/id_dsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.2
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH_5*
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr 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: Server host key: RSA 15:6e:7a:db:35:7c:6a:ba:3e:c0:c1:24:4d:5a:be:a8
debug1: Host 'server.domain' is known and matches the RSA host key.
debug1: Found key in /Users/Hung/.ssh/known_hosts:13
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /Users/Hung/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 279
debug1: Authentication succeeded (publickey).
Authenticated to server.domain ([server.ip.address]:22).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LC_CTYPE = UTF-8
xhg
  • 1,850
  • 2
  • 21
  • 35

1 Answers1

5

It could be a problem with the MTU on the VPN link or the wifi link. You can try to lower the MTU size on your VPN (assuming tap0 is your VPN device, on Linux): 

ifconfig tap0 mtu 1200

Windows and Mac have other mechanisms to set the MTU, I haven't tried them:

The Maximum Transmission Unit (MTU) is the maximum size of a packet you can send over your link. If your link to the server has a MTU of 1500, but you configure your VPN to run with a MTU of 1484, then big packets from the server have to be fragmented into two parts to fit into the 1484-sized packets. Some cheap routers/firewalls don't handle this properly and only forward the first packet. So as soon as you try to send something big, which has to be fragmented, only the first fragment makes it through. As a result, your client will wait for the 2nd fragment to reassemble the whole packet until the timeout, which would stall your connected. This could happen in the moment when the server sends you a big packet, for example a large "welcome screen" just in the moment you logged in.

Source: http://www.snailbook.com/faq/mtu-mismatch.auto.html

Benedikt Köppel
  • 4,853
  • 4
  • 32
  • 42
  • I may not be able to go through the the situation again now, but your answer really provide a likely solution. – xhg Dec 26 '15 at 15:42
  • Yup I had a very similar problem, my SSH session was stuck when the key exchange happened, probably because I have 4096 byte long keys. I fixed it by setting the MTU on my VPN. – Benedikt Köppel Dec 26 '15 at 15:44
  • 2
    I'm having this exact problem, but not on a VPN. I set MTU to 100 in both ends and the problem persists. I can open sockets with nc. SSH just does not want to work. Any ideas? – Gazihan Alankus Nov 27 '17 at 14:37
  • "Some cheap routers/firewalls don't handle this properly" Also the expensive ones. The second fragment doesn't contain a TCP port number, so a firewall that filters by port, it needs another layer of complexity (per-packet fragment tracking). – kubanczyk Jan 24 '20 at 08:05