SSH connection established but stuck

Question

I can use ssh for the server in my house, but I can not ssh with some kind of VPN or public Wi-Fi (not all). when I type ssh -v [e-mail] , I got the following:

 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 answer as long as possible. can anyone help? the following is normal:

 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 [e-mail] debug1: Entering interactive session. debug1: Sending environment. debug1: Sending env LC_CTYPE = UTF-8 

Answer 1

This may be a problem with the MTU on the VPN connection or in the wifi link. You can try to reduce the MTU size on your VPN (assuming tap0 is your Linux VPN device):

 ifconfig tap0 mtu 1200 

Windows and Mac have other mechanisms for installing MTU, I have not tried them:

• Windows: http://www.richard-slater.co.uk/archives/2009/10/23/change-your-mtu-under-vista-windows-7-or-windows-8/
• Mac OS X: https://support.zen.co.uk/kb/Knowledgebase/Changing-the-MTU-size-in-Mac-OS-X-10.6-to-10.9

Maximum Transmission Unit (MTU) is the maximum packet size that you can send via your link. If your server link has MTU 1500, but you are setting up a VPN to work with MTU 1484, then large packets from the server must be split into two in order to fit into 1484 packets. Some cheap routers / firewalls cannot handle this correctly and only forward the first packet. Therefore, as soon as you try to send something big that needs to be fragmented, only the first fragment will skip. As a result, your client will wait until the second fragment collects the entire packet before the timeout, which will stop your connection. This can happen when the server sends you a large packet, for example, a large "welcome screen" only at the moment you are logged in.

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