Menu
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 [email protected], 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 [email protected]
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LC_CTYPE = UTF-8
318
Most common reasons for hanging SSH terminals are: Network: If you are connected over wifi, make sure that your Internet connection is fine. Busy front-end server: When you connect to a cluster, you SSH to one of the front-ends.
Troubleshooting steps:Verify that the host IP address is correct. Verify the firewall rules, check the inbound rules allowed by the security group. Verify the port number allowed for ssh. Verify that the service is running properly.
Methods for how to disconnect from SSH session The first way to disconnect from an SSH session is with the exit command. Issue this command on the remote terminal that you are currently logged in to. The second way to disconnect from an SSH session is with the logout command.
Sometimes it becomes very irritating for the user. The user will require to increase the SSH connection timeout to solve this problem; It can be done in two ways. One way is to set the keep-alive options in the server configuration file, and another way is to set the keep-alive option in the client configuration file.
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
116
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
