Description of problem: In some environments, I can no longer connect via SSH. The client is Fedora 19 OpenSSH_6.2p2, the server is RHEL 6.4 with openssh-server-5.3p1. Other SSH clients can successfully connect to the same server. I can successfully connect to other SSH servers. After investigating this, it looks like the issue described here: http://www.held.org.il/blog/2011/05/the-myterious-case-of-broken-ssh-client-connection-reset-by-peer/ SSH output: $ ssh -v jon@HOSTNAME OpenSSH_6.2p2, OpenSSL 1.0.1e-fips 11 Feb 2013 debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 50: Applying options for * debug1: Connecting to HOSTNAME [IPADDRESS] port 22. debug1: Connection established. debug1: identity file /home/jon/.ssh/id_rsa type 1 debug1: identity file /home/jon/.ssh/id_rsa-cert type -1 debug1: identity file /home/jon/.ssh/id_dsa type -1 debug1: identity file /home/jon/.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 Connection closed by IPADDRESS With the workaround: $ ssh -v -c aes256-ctr jon@HOSTNAME OpenSSH_6.2p2, OpenSSL 1.0.1e-fips 11 Feb 2013 debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 50: Applying options for * debug1: Connecting to HOSTNAME [IPADDRESS] port 22. debug1: Connection established. debug1: identity file /home/jon/.ssh/id_rsa type 1 debug1: identity file /home/jon/.ssh/id_rsa-cert type -1 debug1: identity file /home/jon/.ssh/id_dsa type -1 debug1: identity file /home/jon/.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 aes256-ctr hmac-md5 none debug1: kex: client->server aes256-ctr hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<4096<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 90:3f:09:86:87:3b:f5:d5:c1:6c:f0:ef:fc:3f:15:85 debug1: Host 'HOSTNAME' is known and matches the RSA host key. debug1: Found key in /home/jon/.ssh/known_hosts:5 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,password debug1: Next authentication method: gssapi-keyex debug1: No valid Key exchange context debug1: Next authentication method: gssapi-with-mic debug1: Unspecified GSS failure. Minor code may provide more information No Kerberos credentials available debug1: Unspecified GSS failure. Minor code may provide more information No Kerberos credentials available debug1: Unspecified GSS failure. Minor code may provide more information debug1: Unspecified GSS failure. Minor code may provide more information No Kerberos credentials available debug1: Next authentication method: publickey debug1: Offering RSA public key: /home/jon/.ssh/id_rsa debug1: Server accepts key: pkalg ssh-rsa blen 279 debug1: Authentication succeeded (publickey). Authenticated to HOSTNAME ([IPADDRESS]:22). debug1: channel 0: new [client-session] debug1: Requesting no-more-sessions debug1: Entering interactive session. debug1: Sending environment. debug1: Sending env XMODIFIERS = @im=ibus debug1: Sending env LANG = en_US.utf8 Last login: Wed Oct 2 16:58:56 2013 from 184.71.161.246 How reproducible: 100% Actual results: Unable to connect to the server via SSH. Expected results: Connect to server every time.
Versions on F19 client: openssh-6.2p2-5.fc19.x86_64 openssh-clients-6.2p2-5.fc19.x86_64 openssh-server-sysvinit-6.2p2-5.fc19.x86_64 openssh-server-6.2p2-5.fc19.x86_64 Versions on RHEL 6.4 Server: openssh-clients-5.3p1-84.1.el6.x86_64 openssh-server-5.3p1-84.1.el6.x86_64 openssh-5.3p1-84.1.el6.x86_64 If I can provide any additional information that will help, please let me know.
+1 I'm seeing this as well. F19 to RHEL 6.4, same versions.
I am also seeing this between two RHEL 6.4 servers, same versions as above
Seeing this as well, F20 to CentOS 5.6, workaround suggested in comment #1 didn't work.
Same situation, different fix. Cygwin SSH to RH6.4 CYGWIN SSH: $ ssh -V OpenSSH_6.5p1, OpenSSL 1.0.1f 6 Jan 2014 RH6.4: $ ssh -V OpenSSH_5.3p1, OpenSSL 1.0.0-fips 29 Mar 2010 Fails at "expecting SSH2_MSG_KEX_DH_GEX_GROUP" debug2: kex_parse_kexinit: reserved 0 debug2: mac_setup: found hmac-md5 debug1: kex: server->client aes128-ctr hmac-md5 none debug2: mac_setup: found hmac-md5 debug1: kex: client->server aes128-ctr hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<3072<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP Connection closed by xxxxxxxxx "ssh -Q mac" revealed a very long list of MAC options compiled into the client. $ ssh -Q mac hmac-sha1 hmac-sha1-96 hmac-sha2-256 hmac-sha2-512 hmac-md5 hmac-md5-96 hmac-ripemd160 hmac-ripemd160 umac-64 umac-128 hmac-sha1-etm hmac-sha1-96-etm hmac-sha2-256-etm hmac-sha2-512-etm hmac-md5-etm hmac-md5-96-etm hmac-ripemd160-etm umac-64-etm umac-128-etm Workaround is either: 1. Fix/create the ssh_config (uncomment MACs in there which is considerably shorter) 2. pass -m on ssh command line with a shorter list Both of these allow it to suddenly work. The point of failure for me seems to be when the list is > 72 Characters: (based on other reported "fixes" it could be a combined length for Cipher and MACs) FAILS: ssh -m hmac-md5,hmac-sha1,,,,,,,,,,,,,,,,,,,,aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa WORKS: ssh -m hmac-md5,hmac-sha1,,,,,,,,,,,,,,,,,,,,aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
This message is a reminder that Fedora 20 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 20. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '20'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 20 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.