SFTP failing with no error that I can determine at SSH2_MSG_SERVICE_REQUEST sent

Disillusionist · 11-24-2016, 11:45 AM

I have tried searching both within the Linux Questions threads and through Google search, but my abilities have failed me.

I am getting a "Connection reset by peer" message when trying to connect to an SFTP site from within Linux.

I can connect without issues when I use FileZilla client or WinSCP from Windows, but from the command line the connection fails and I cannot see a reason in the verbose output (see below):

Code:

[root@host1 ~]# sftp -vvv user@server.namechanged.com
OpenSSH_6.6.1, OpenSSL 1.0.1e-fips 11 Feb 2013
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 56: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to server.namechanged.com [x.x.x.x] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/id_rsa type -1
debug1: identity file /root/.ssh/id_rsa-cert type -1
debug1: identity file /root/.ssh/id_dsa type -1
debug1: identity file /root/.ssh/id_dsa-cert type -1
debug1: identity file /root/.ssh/id_ecdsa type -1
debug1: identity file /root/.ssh/id_ecdsa-cert type -1
debug1: identity file /root/.ssh/id_ed25519 type -1
debug1: identity file /root/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6.1
debug1: Remote protocol version 2.0, remote software version CoreFTP-0.3.2
debug1: no match: CoreFTP-0.3.2
debug2: fd 3 setting O_NONBLOCK
debug3: load_hostkeys: loading entries for host "server.namechanged.com" from file "/root/.ssh/known_hosts"
debug3: load_hostkeys: found key type RSA in file /root/.ssh/known_hosts:4
debug3: load_hostkeys: loaded 1 keys
debug3: order_hostkeyalgs: prefer hostkeyalgs: ssh-rsa-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-rsa
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: curve25519-sha256@libssh.org,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-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-rsa,ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-ed25519-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ssh-dss-cert-v00@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,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-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-sha1,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-sha1,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,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: diffie-hellman-group1-sha1,diffie-hellman-group14-sha1
debug2: kex_parse_kexinit: ssh-rsa
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: hmac-sha1
debug2: kex_parse_kexinit: hmac-sha1
debug2: kex_parse_kexinit: none,none
debug2: kex_parse_kexinit: none,none
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: setup hmac-sha1
debug1: kex: server->client aes128-ctr hmac-sha1 none
debug2: mac_setup: setup hmac-sha1
debug1: kex: client->server aes128-ctr hmac-sha1 none
debug1: kex: diffie-hellman-group14-sha1 need=20 dh_need=20
debug1: kex: diffie-hellman-group14-sha1 need=20 dh_need=20
debug2: bits set: 1021/2048
debug1: sending SSH2_MSG_KEXDH_INIT
debug1: expecting SSH2_MSG_KEXDH_REPLY
debug1: Server host key: RSA 44:4d:8a:bf:d6:55:d9:85:81:1a:f7:d3:98:07:c2:c0
debug3: load_hostkeys: loading entries for host "server.namechanged.com" from file "/root/.ssh/known_hosts"
debug3: load_hostkeys: found key type RSA in file /root/.ssh/known_hosts:4
debug3: load_hostkeys: loaded 1 keys
debug3: load_hostkeys: loading entries for host "x.x.x.x" from file "/root/.ssh/known_hosts"
debug3: load_hostkeys: found key type RSA in file /root/.ssh/known_hosts:4
debug3: load_hostkeys: loaded 1 keys
debug1: Host 'server.namechanged.com' is known and matches the RSA host key.
debug1: Found key in /root/.ssh/known_hosts:4
debug2: bits set: 1007/2048
debug1: ssh_rsa_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: SSH2_MSG_SERVICE_REQUEST sent
Connection closed by x.x.x.x
Couldn't read packet: Connection reset by peer

Emerson · 11-24-2016, 01:15 PM

Can you connect as user? Root really should not make remote connections, it is a local admin account.

Disillusionist · 11-24-2016, 01:58 PM

Hi Emerson,

I get exactly the same issues using a standard account, was trying root to ensure it wasn't a local permission thing.

Emerson · 11-24-2016, 03:09 PM

Can you look at the log on the server side?

Disillusionist · 11-24-2016, 03:34 PM

Wish I could, unfortunately the server is a third party service that I have no access to.

I am able to connect to it using windows based sftp tools but am trying to automate an sftp upload from Linux.

Emerson · 11-24-2016, 03:48 PM

Don't know, all boxes I logged on show sha256 while your connection seems to try sha1.

Disillusionist · 11-24-2016, 04:06 PM

I have tried from various different Linux severs and seem to be getting the same issue so looks like I'm going to have to log a call with the 3rd party provider

Thanks for the 2nd pair of eyes

c0wb0y · 11-28-2016, 08:47 PM

Quote:

Originally Posted by Disillusionist

I have tried searching both within the Linux Questions threads and through Google search, but my abilities have failed me.

I am getting a "Connection reset by peer" message when trying to connect to an SFTP site from within Linux.

I can connect without issues when I use FileZilla client or WinSCP from Windows, but from the command line the connection fails and I cannot see a reason in the verbose output (see below):

Code:

[root@host1 ~]# sftp -vvv user@server.namechanged.com
---
debug1: Remote protocol version 2.0, remote software version CoreFTP-0.3.2
debug1: no match: CoreFTP-0.3.2
---

CoreFTP seems not to like Linux. Yes, it seems like submitting a ticket to provider is the best option.