SSH Connection Disconnects Upon Modifying System File or Directory

0

I am experiencing an OpenSSH problem in Cygwin under Windows 7. My connection sometimes gets "closed by remote host". As near I can tell, this is happening when I modify a system file or directory. The modification is successful---but the SSH session dies!

I am a domain user, and I do have administrative privileges.

Version information of the software involved is as follows:

myUserName@myHostName ~
$ uname -a
CYGWIN_NT-6.1 myHostName 1.7.16(0.262/5/3) 2012-07-20 22:55 i686 Cygwin

myUserName@myHostName ~
$ ssh -V
OpenSSH_6.0p1, OpenSSL 1.0.1c 10 May 2012

What's shown below is a client-side log. After successfully logging in, I execute the command "touch /etc/junk" as an example. The command succeeds, but then the SSH session immediately dies. You'll also note in the log below that the server (sshd) also dies.

For purposes of creating this example, I simply connected to localhost. However, the same problem happens regardless of where I connect from.

myUserName@myHostName ~
$ ssh -vvv 127.0.0.1
OpenSSH_6.0p1, OpenSSL 1.0.1c 10 May 2012
debug1: Reading configuration data /etc/ssh_config
debug2: ssh_connect: needpriv 0
debug1: Connecting to 127.0.0.1 [127.0.0.1] port 22.
debug1: Connection established.
debug1: identity file /home/myUserName/.ssh/id_rsa type -1
debug1: identity file /home/myUserName/.ssh/id_rsa-cert type -1
debug1: identity file /home/myUserName/.ssh/id_dsa type -1
debug1: identity file /home/myUserName/.ssh/id_dsa-cert type -1
debug1: identity file /home/myUserName/.ssh/id_ecdsa type -1
debug1: identity file /home/myUserName/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.0
debug1: match: OpenSSH_6.0 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.0
debug2: fd 3 setting O_NONBLOCK
debug3: load_hostkeys: loading entries for host "127.0.0.1" from file "/home/myUserName/.ssh/known_hosts"
debug3: load_hostkeys: found key type ECDSA in file /home/myUserName/.ssh/known_hosts:1
debug3: load_hostkeys: loaded 1 keys
debug3: load_hostkeys: loading entries for host "127.0.0.1" from file "/etc/ssh_known_hosts"
debug3: load_hostkeys: loaded 0 keys
debug3: order_hostkeyalgs: prefer hostkeyalgs: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-rsa-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-dss-cert-v00@openssh.com,ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ecdsa-sha2-nistp256
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
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: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA 5e:af:d7:eb:52:5f:b7:6e:e3:46:38:c6:91:6a:69:24
debug3: load_hostkeys: loading entries for host "127.0.0.1" from file "/home/myUserName/.ssh/known_hosts"
debug3: load_hostkeys: found key type ECDSA in file /home/myUserName/.ssh/known_hosts:1
debug3: load_hostkeys: loaded 1 keys
debug3: load_hostkeys: loading entries for host "127.0.0.1" from file "/etc/ssh_known_hosts"
debug3: load_hostkeys: loaded 0 keys
debug1: Host '127.0.0.1' is known and matches the ECDSA host key.
debug1: Found key in /home/myUserName/.ssh/known_hosts:1
debug1: ssh_ecdsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /home/myUserName/.ssh/id_rsa (0x0)
debug2: key: /home/myUserName/.ssh/id_dsa (0x0)
debug2: key: /home/myUserName/.ssh/id_ecdsa (0x0)
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug3: start over, passed a different list publickey,password,keyboard-interactive
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /home/myUserName/.ssh/id_rsa
debug3: no such identity: /home/myUserName/.ssh/id_rsa
debug1: Trying private key: /home/myUserName/.ssh/id_dsa
debug3: no such identity: /home/myUserName/.ssh/id_dsa
debug1: Trying private key: /home/myUserName/.ssh/id_ecdsa
debug3: no such identity: /home/myUserName/.ssh/id_ecdsa
debug2: we did not send a packet, disable method
debug3: authmethod_lookup keyboard-interactive
debug3: remaining preferred: password
debug3: authmethod_is_enabled keyboard-interactive
debug1: Next authentication method: keyboard-interactive
debug2: userauth_kbdint
debug2: we sent a keyboard-interactive packet, wait for reply
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug3: userauth_kbdint: disable: no info_req_seen
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred:
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
myUserName@127.0.0.1's password:
debug3: packet_send2: adding 48 (len 74 padlen 6 extra_pad 64)
debug2: we sent a password packet, wait for reply
debug1: Authentication succeeded (password).
Authenticated to 127.0.0.1 ([127.0.0.1]:22).
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug2: callback start
debug2: client_session2_setup: id 0
debug2: fd 3 setting TCP_NODELAY
debug3: packet_set_tos: set IP_TOS 0x10
debug2: channel 0: request pty-req confirm 1
debug2: channel 0: request shell confirm 1
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel_input_status_confirm: type 99 id 0
debug2: PTY allocation request accepted on channel 0
debug2: channel 0: rcvd adjust 2097152
debug2: channel_input_status_confirm: type 99 id 0
debug2: shell request accepted on channel 0
Last login: Tue Jun 20 14:08:11 2017 from 127.0.0.1

myUserName@myHostName ~
$ touch /etc/junk
debug1: channel 0: free: client-session, nchannels 1
debug3: channel 0: status: The following connections are open:
  #0 client-session (t4 r0 i0/0 o0/0 fd 4/5 cc -1)

Connection to 127.0.0.1 closed by remote host.
Connection to 127.0.0.1 closed.
Transferred: sent 2648, received 2232 bytes, in 12.5 seconds
Bytes per second: sent 211.9, received 178.6
debug1: Exit status -1

myUserName@myHostName ~
$ ls -l /etc/junk
-rw-r--r-- 1 myUserName Domain Users 0 Jun 20 14:19 /etc/junk

myUserName@myHostName ~
$ ps -elf | grep -i ssh

myUserName@myHostName ~
$

On the server-side log (/var/log/sshd.log), I see only the complaint "Could not load host key: /etc/ssh_host_dsa_key". I purposely deleted the DSA key, so this is expected (and clearly unrelated).

Is anybody able to see where I'm running into trouble and how I can fix this?

Dave

Posted 2017-06-20T21:45:06.710

Reputation: 597

It might be a bug in Cygwin. Is there any particular reason you're running a 6 year old version? You might want to try upgrading... – jjlin – 2017-06-21T03:00:24.813

Unfortunately, we're in a tightly-controlled environment where only approved machine images may be used. Updating our Cygwin image is an option that (admittedly needlessly) is not being made available to us. I fear you're right and this it's a bug, which means we're, well, stuck... – Dave – 2017-06-21T14:49:22.863

Have we confirmed whether this is a bug or not yet? – music2myear – 2017-06-23T18:25:35.647

No. Any suggestions on how to do ao??? – Dave – 2017-06-23T18:28:11.830

No answers