Bug 1014871 - SSH fails to connect in some environments "Connection closed by <IP ADDRESS>"
SSH fails to connect in some environments "Connection closed by <IP ADDRESS>"
Status: CLOSED EOL
Product: Fedora
Classification: Fedora
Component: openssh (Show other bugs)
20
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Petr Lautrbach
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-10-02 20:43 EDT by Jon Dufresne
Modified: 2015-06-29 08:31 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-06-29 08:31:44 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jon Dufresne 2013-10-02 20:43:12 EDT
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@openssh.com
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.
Comment 1 Jon Dufresne 2013-10-03 11:47:16 EDT
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.
Comment 2 Graham White 2013-10-14 09:06:09 EDT
+1 I'm seeing this as well.  F19 to RHEL 6.4, same versions.
Comment 3 John Dempsey 2013-10-29 16:10:01 EDT
I am also seeing this between two RHEL 6.4 servers, same versions as above
Comment 4 Elad Alfassa 2014-02-16 06:15:30 EST
Seeing this as well, F20 to CentOS 5.6, workaround suggested in comment #1 didn't work.
Comment 5 tch 2014-03-11 16:08:48 EDT
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@openssh.com
umac-64@openssh.com
umac-128@openssh.com
hmac-sha1-etm@openssh.com
hmac-sha1-96-etm@openssh.com
hmac-sha2-256-etm@openssh.com
hmac-sha2-512-etm@openssh.com
hmac-md5-etm@openssh.com
hmac-md5-96-etm@openssh.com
hmac-ripemd160-etm@openssh.com
umac-64-etm@openssh.com
umac-128-etm@openssh.com

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
Comment 6 Fedora End Of Life 2015-05-29 05:30:18 EDT
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.
Comment 7 Fedora End Of Life 2015-06-29 08:31:44 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.