SSH works in putty but not terminal
Solution 1
Solution found for me via the following URL: http://www.held.org.il/blog/2011/05/the-myterious-case-of-broken-ssh-client-connection-reset-by-peer/
It even does a pretty good job of explaining what is going on.
Ultimately, I added the following to /etc/ssh/ssh_config:
Host *
SendEnv LANG LC_*
HashKnownHosts yes
GSSAPIAuthentication yes
GSSAPIDelegateCredentials no
Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc
HostKeyAlgorithms ssh-rsa,ssh-dss
MACs hmac-md5,hmac-sha1,hmac-ripemd160
Neither Ciphers, or HostKeyAlgorithms worked on their own, pretty sure MACs put me over the top to get this to work, but I can't be sure, put many hours into getting this solved. I hope this can at least help somebody else.
Edit: This (sometimes) fixes the problem, but probably not in the way you want. --jcwenger
These settings appear to (as a side effect) change the way the ssh client emits packets, and happen to cause it to emit smaller packets. This isn't fixing the problem; it just, sometimes, makes it so that the real problem (MTU fragmentation interacting with stupid firewall rule implementations) isn't triggered.
The correct solution is to set an MTU that works end to end.
Having to manually set MTU to a smaller number to ensure no fragmentation occurs isn't any cleaner (we as users shouldn't have to manually take steps to counter problems caused by our network teams)... but it's at least directly dealing with the actual cause in a reliable and provable way, rather than screwing up SSH's cipher settings in a way that, as a side effect, when the stars align, happens to cause it to not make big packets.
Also, SSH isn't the only thing that makes big packets. Setting MTU keeps the same thing from happening to other protocols too.
Solution 2
This worked for me ...
ifconfig eth0 mtu 576
http://fred-web.blogspot.com.au/2012/10/ssh-hang-on-expecting.html
Solution 3
This fixed the MTU issue without having to hardcode some value, it will fix it for ssh and any other protocol effected by this. As root run the following:
echo 2 > /proc/sys/net/ipv4/tcp_mtu_probing
You can read more about the issue and solution here and here.
Solution 4
I was able to solve this issue by forcing to use IPv4 with
ssh -4 [email protected]
Since I'm on a Mac I don't know what are the MTU settings here or how to change them, but thought that others may benefit from this.
Solution 5
Did some looking and found the following suggestion here:
Try making sure the following line in your /etc/ssh/ssh_config (NOT sshd_config) is NOT commented out:
Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc
You also might try reverting that file back to the default and trying again, i.e. uninstall and reinstall openssh-client
IIRC the name of the package.
Related videos on Youtube
Get Off My Lawn
Currently working on a node web framework Red5 Http Server, which is still just beta, but feel free to check it out! Any feedback would be great! You can checkout the code on Github, this includes the website, installer and framework. Thanks for checking it out!
Updated on September 18, 2022Comments
-
Get Off My Lawn over 1 year
When I try to ssh this in a terminal:
ssh [email protected]
I get the following error:
Connection closed by 69.163.227.82
When I use putty, I am able to connect to the server. Why is this happening, and how can I get this to work in a terminal?
ssh -v [email protected]
OpenSSH_6.0p1 (CentrifyDC build 5.1.0-472) (CentrifyDC build 5.1.0-472), OpenSSL 0.9.8w 23 Apr 2012 debug1: Reading configuration data /etc/centrifydc/ssh/ssh_config debug1: /etc/centrifydc/ssh/ssh_config line 52: Applying options for * debug1: Connecting to sub.domain.com [69.163.227.82] port 22. debug1: Connection established. debug1: identity file /home/ryannaddy/.ssh/id_rsa type -1 debug1: identity file /home/ryannaddy/.ssh/id_rsa-cert type -1 debug1: identity file /home/ryannaddy/.ssh/id_dsa type -1 debug1: identity file /home/ryannaddy/.ssh/id_dsa-cert type -1 debug1: identity file /home/ryannaddy/.ssh/id_ecdsa type -1 debug1: identity file /home/ryannaddy/.ssh/id_ecdsa-cert type -1 debug1: Remote protocol version 2.0, remote software version OpenSSH_5.1p1 Debian-5 debug1: match: OpenSSH_5.1p1 Debian-5 pat OpenSSH_5* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_6.0 debug1: Miscellaneous failure Cannot resolve network address for KDC in requested realm debug1: Miscellaneous failure Cannot resolve network address for KDC in requested realm 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 Connection closed by 69.163.227.82
-
James Sneeringer about 11 yearsWhat does
ssh -v [email protected]
show? -
Get Off My Lawn about 11 yearsI updated the main question. Also the server should ask for a password, there are no ssh keys required to login.
-
Kruug about 11 yearsDid you change any settings from default in PuTTY?
-
Kruug about 11 yearsAlso, have you tried
[email protected]
? Leave out thesub
. -
Get Off My Lawn about 11 years@Kruug all putty settings were left as the defaults, and yes I have tried a few combinations:
domain.com
,subdomain.com
,[email protected]
,[email protected]
,69.163.227.82
,[email protected]
-
Kruug about 11 yearsTry
ssh -vvv [email protected]
. That should give more detailed output. -
James Sneeringer about 11 yearsYou're using Centrify's build of OpenSSH, which implies your system is AD-integrated. Active Directory uses Kerberos, and OpenSSH is complaining that it can't find the Kerberos KDC, so it's bailing out. What does your
/etc/krb5.conf
look like? -
Get Off My Lawn about 11 years@JamesSneeringer it has work related stuff in it is that safe to post?
-
-
Get Off My Lawn about 11 yearsThat didn't fix it :(
-
Tombart over 10 yearsthanks, in my case just the last line
MACs hmac-md5,hmac-sha1,hmac-ripemd160
was enough -
Jason over 10 yearsI had a problem with github - git pull / git push - nothing happened. Tried ssh -T -v [email protected] and got the same error. Used this to solve it. Thank you!
-
lfagundes about 10 yearsI had a similar problem and tried this solution. One side effect is that any connection to a known host would then accuse a host key change.
-
jcwenger about 9 yearsAll of these patches are treating the symptom and not the cause. Reducing cipher size has the potential to prevent MTU fragmentation... which is the real problem, brought up by @jagguli below.
-
Jeff Wright over 8 yearsAdding the line "HostKeyAlgorithms ssh-rsa,ssh-dss" into /etc/ssh/ssh_config fixed my issue with not being able to SSH into a Zyxel modem. All the other lines in the above tetbox were already in place on my machine. Thank you for the tip!
-
Scott - Слава Україні about 6 yearsWhy do you believe that this command will solve the problem?
-
Jorj over 5 yearsThat option forces ssh to use IP4 only. I am on Mac too and it did NOT solve my issue.
-
Jorj over 5 yearsExplanation: "It turns out that the kernel /proc file system provides an easy way to enable and disable TCP MTU Probing by changing a value in the ‘file’ /proc/sys/net/ipv4/tcp_mtu_probing. A value of 0 = disabled; 1 = enabled when a black hole router is detected; 2 = always enabled."