Connection reset by peer using sshfs
I am using a fuse/sshfs mount which worked fine so far. Now I had to reinstall the server system and suddenly getting the classic read: Connection reset by peer
error. I am using public key authentication and copied my key to the newly installed system. Normal ssh login works fine. I changed the log to debug but sadly this doesn't give me any useful information:
sshd[2077]: debug1: Forked child 2198.
sshd[2198]: Set /proc/self/oom_score_adj to 0
sshd[2198]: debug1: rexec start in 5 out 5 newsock 5 pipe 7 sock 8
sshd[2198]: debug1: inetd sockets after dupping: 3, 3
sshd[2198]: Connection from 192.168.1.6 port 47991
sshd[2198]: debug1: Client protocol version 2.0; client software version OpenSSH_6.1p1 Debian-4
sshd[2198]: debug1: match: OpenSSH_6.1p1 Debian-4 pat OpenSSH*
sshd[2198]: debug1: Enabling compatibility mode for protocol 2.0
sshd[2198]: debug1: Local version string SSH-2.0-OpenSSH_6.1p1 Debian-4
sshd[2198]: debug1: permanently_set_uid: 103/65534 [preauth]
sshd[2198]: debug1: list_hostkey_types: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256 [preauth]
sshd[2198]: debug1: SSH2_MSG_KEXINIT sent [preauth]
sshd[2198]: debug1: SSH2_MSG_KEXINIT received [preauth]
sshd[2198]: debug1: kex: client->server aes128-ctr hmac-md5 none [preauth]
sshd[2198]: debug1: kex: server->client aes128-ctr hmac-md5 none [preauth]
sshd[2198]: debug1: expecting SSH2_MSG_KEX_ECDH_INIT [preauth]
sshd[2198]: debug1: SSH2_MSG_NEWKEYS sent [preauth]
sshd[2198]: debug1: expecting SSH2_MSG_NEWKEYS [preauth]
sshd[2198]: Connection closed by 192.168.1.6 [preauth]
sshd[2198]: debug1: do_cleanup [preauth]
sshd[2198]: debug1: monitor_read_log: child log fd closed
sshd[2198]: debug1: do_cleanup
sshd[2198]: debug1: Killing privsep child 2199
Does anyone have an idea what I am missing here?
UPDATE
The auth.log
with debug level 3:
sshd[2455]: debug3: fd 5 is not O_NONBLOCK
sshd[2455]: debug1: Forked child 2456.
sshd[2455]: debug3: send_rexec_state: entering fd = 8 config len 751
sshd[2455]: debug3: ssh_msg_send: type 0
sshd[2455]: debug3: send_rexec_state: done
sshd[2456]: debug3: oom_adjust_restore
sshd[2456]: Set /proc/self/oom_score_adj to 0
sshd[2456]: debug1: rexec start in 5 out 5 newsock 5 pipe 7 sock 8
sshd[2456]: debug1: inetd sockets after dupping: 3, 3
sshd[2456]: Connection from 192.168.1.6 port 50037
sshd[2456]: debug1: Client protocol version 2.0; client software version OpenSSH_6.1p1 Debian-4
sshd[2456]: debug1: match: OpenSSH_6.1p1 Debian-4 pat OpenSSH*
sshd[2456]: debug1: Enabling compatibility mode for protocol 2.0
sshd[2456]: debug1: Local version string SSH-2.0-OpenSSH_6.1p1 Debian-4
sshd[2456]: debug2: fd 3 setting O_NONBLOCK
sshd[2456]: debug2: Network child is on pid 2457
sshd[2456]: debug3: preauth child monitor started
sshd[2456]: debug3: privsep user:group 103:65534 [preauth]
sshd[2456]: debug1: permanently_set_uid: 103/65534 [preauth]
sshd[2456]: debug1: list_hostkey_types: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256 [preauth]
sshd[2456]: debug1: SSH2_MSG_KEXINIT sent [preauth]
sshd[2456]: debug1: SSH2_MSG_KEXINIT received [preauth]
sshd[2456]: 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 [preauth]
sshd[2456]: debug2: kex_parse_kexinit: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256 [preauth]
sshd[2456]: 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 [preauth]
sshd[2456]: 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 [preauth]
sshd[2456]: debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 [preauth]
sshd[2456]: debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 [preauth]
sshd[2456]: debug2: kex_parse_kexinit: none,zlib@openssh.com [preauth]
sshd[2456]: debug2: kex_parse_kexinit: none,zlib@openssh.com [preauth]
sshd[2456]: debug2: kex_parse_kexinit: [preauth]
sshd[2456]: debug2: kex_parse_kexinit: [preauth]
sshd[2456]: debug2: kex_parse_kexinit: first_kex_follows 0 [preauth]
sshd[2456]: debug2: kex_parse_kexinit: reserved 0 [preauth]
sshd[2456]: 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 [preauth]
sshd[2456]: 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 [preauth]
sshd[2456]: 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 [preauth]
sshd[2456]: 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 [preauth]
sshd[2456]: debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 [preauth]
sshd[2456]: debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 [preauth]
sshd[2456]: debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib [preauth]
sshd[2456]: debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib [preauth]
sshd[2456]: debug2: kex_parse_kexinit: [preauth]
sshd[2456]: debug2: kex_parse_kexinit: [preauth]
sshd[2456]: debug2: kex_parse_kexinit: first_kex_follows 0 [preauth]
sshd[2456]: debug2: kex_parse_kexinit: reserved 0 [preauth]
sshd[2456]: debug2: mac_setup: found hmac-md5 [preauth]
sshd[2456]: debug1: kex: client->server aes128-ctr hmac-md5 none [preauth]
sshd[2456]: debug2: mac_setup: found hmac-md5 [preauth]
sshd[2456]: debug1: kex: server->client aes128-ctr hmac-md5 none [preauth]
sshd[2456]: debug1: expecting SSH2_MSG_KEX_ECDH_INIT [preauth]
sshd[2456]: debug3: mm_key_sign entering [preauth]
sshd[2456]: debug3: mm_request_send entering: type 5 [preauth]
sshd[2456]: debug3: mm_key_sign: waiting for MONITOR_ANS_SIGN [preauth]
sshd[2456]: debug3: mm_request_receive_expect entering: type 6 [preauth]
sshd[2456]: debug3: mm_request_receive entering [preauth]
sshd[2456]: debug3: mm_request_receive entering
sshd[2456]: debug3: monitor_read: checking request 5
sshd[2456]: debug3: mm_answer_sign
sshd[2456]: debug3: mm_answer_sign: signature 0x7f9b687c7680(100)
sshd[2456]: debug3: mm_request_send entering: type 6
sshd[2456]: debug2: monitor_read: 5 used once, disabling now
sshd[2456]: debug2: kex_derive_keys [preauth]
sshd[2456]: debug2: set_newkeys: mode 1 [preauth]
sshd[2456]: debug1: SSH2_MSG_NEWKEYS sent [preauth]
sshd[2456]: debug1: expecting SSH2_MSG_NEWKEYS [preauth]
sshd[2456]: Connection closed by 192.168.1.6 [preauth]
sshd[2456]: debug1: do_cleanup [preauth]
sshd[2456]: debug3: PAM: sshpam_thread_cleanup entering [preauth]
sshd[2456]: debug1: monitor_read_log: child log fd closed
sshd[2456]: debug3: mm_request_receive entering
sshd[2456]: debug1: do_cleanup
sshd[2456]: debug3: PAM: sshpam_thread_cleanup entering
sshd[2456]: debug1: Killing privsep child 2457
UPDATE
I tried a manual sshfs
mount and I also get read: Connection reset by peer
. I then added the debuging options and also got Permission denied (publickey).
. This is strange since the public key is in place and works fine otherwise. I also use my user for the ssh connection and manually specify the private key file. Could this be an issue with the root account not beeing able to access the correct public key on the server somewhere? I'm executing
sudo sshfs myuser@myserver:/mnt/foo /mnt/foo -o IdentityFile=/home/myuser/.ssh/id_rsa
and the relevant log part is
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/myuser/.ssh/id_rsa
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.
Permission denied (publickey).
read: Connection reset by peer
ssh sshfs
|
show 7 more comments
I am using a fuse/sshfs mount which worked fine so far. Now I had to reinstall the server system and suddenly getting the classic read: Connection reset by peer
error. I am using public key authentication and copied my key to the newly installed system. Normal ssh login works fine. I changed the log to debug but sadly this doesn't give me any useful information:
sshd[2077]: debug1: Forked child 2198.
sshd[2198]: Set /proc/self/oom_score_adj to 0
sshd[2198]: debug1: rexec start in 5 out 5 newsock 5 pipe 7 sock 8
sshd[2198]: debug1: inetd sockets after dupping: 3, 3
sshd[2198]: Connection from 192.168.1.6 port 47991
sshd[2198]: debug1: Client protocol version 2.0; client software version OpenSSH_6.1p1 Debian-4
sshd[2198]: debug1: match: OpenSSH_6.1p1 Debian-4 pat OpenSSH*
sshd[2198]: debug1: Enabling compatibility mode for protocol 2.0
sshd[2198]: debug1: Local version string SSH-2.0-OpenSSH_6.1p1 Debian-4
sshd[2198]: debug1: permanently_set_uid: 103/65534 [preauth]
sshd[2198]: debug1: list_hostkey_types: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256 [preauth]
sshd[2198]: debug1: SSH2_MSG_KEXINIT sent [preauth]
sshd[2198]: debug1: SSH2_MSG_KEXINIT received [preauth]
sshd[2198]: debug1: kex: client->server aes128-ctr hmac-md5 none [preauth]
sshd[2198]: debug1: kex: server->client aes128-ctr hmac-md5 none [preauth]
sshd[2198]: debug1: expecting SSH2_MSG_KEX_ECDH_INIT [preauth]
sshd[2198]: debug1: SSH2_MSG_NEWKEYS sent [preauth]
sshd[2198]: debug1: expecting SSH2_MSG_NEWKEYS [preauth]
sshd[2198]: Connection closed by 192.168.1.6 [preauth]
sshd[2198]: debug1: do_cleanup [preauth]
sshd[2198]: debug1: monitor_read_log: child log fd closed
sshd[2198]: debug1: do_cleanup
sshd[2198]: debug1: Killing privsep child 2199
Does anyone have an idea what I am missing here?
UPDATE
The auth.log
with debug level 3:
sshd[2455]: debug3: fd 5 is not O_NONBLOCK
sshd[2455]: debug1: Forked child 2456.
sshd[2455]: debug3: send_rexec_state: entering fd = 8 config len 751
sshd[2455]: debug3: ssh_msg_send: type 0
sshd[2455]: debug3: send_rexec_state: done
sshd[2456]: debug3: oom_adjust_restore
sshd[2456]: Set /proc/self/oom_score_adj to 0
sshd[2456]: debug1: rexec start in 5 out 5 newsock 5 pipe 7 sock 8
sshd[2456]: debug1: inetd sockets after dupping: 3, 3
sshd[2456]: Connection from 192.168.1.6 port 50037
sshd[2456]: debug1: Client protocol version 2.0; client software version OpenSSH_6.1p1 Debian-4
sshd[2456]: debug1: match: OpenSSH_6.1p1 Debian-4 pat OpenSSH*
sshd[2456]: debug1: Enabling compatibility mode for protocol 2.0
sshd[2456]: debug1: Local version string SSH-2.0-OpenSSH_6.1p1 Debian-4
sshd[2456]: debug2: fd 3 setting O_NONBLOCK
sshd[2456]: debug2: Network child is on pid 2457
sshd[2456]: debug3: preauth child monitor started
sshd[2456]: debug3: privsep user:group 103:65534 [preauth]
sshd[2456]: debug1: permanently_set_uid: 103/65534 [preauth]
sshd[2456]: debug1: list_hostkey_types: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256 [preauth]
sshd[2456]: debug1: SSH2_MSG_KEXINIT sent [preauth]
sshd[2456]: debug1: SSH2_MSG_KEXINIT received [preauth]
sshd[2456]: 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 [preauth]
sshd[2456]: debug2: kex_parse_kexinit: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256 [preauth]
sshd[2456]: 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 [preauth]
sshd[2456]: 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 [preauth]
sshd[2456]: debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 [preauth]
sshd[2456]: debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 [preauth]
sshd[2456]: debug2: kex_parse_kexinit: none,zlib@openssh.com [preauth]
sshd[2456]: debug2: kex_parse_kexinit: none,zlib@openssh.com [preauth]
sshd[2456]: debug2: kex_parse_kexinit: [preauth]
sshd[2456]: debug2: kex_parse_kexinit: [preauth]
sshd[2456]: debug2: kex_parse_kexinit: first_kex_follows 0 [preauth]
sshd[2456]: debug2: kex_parse_kexinit: reserved 0 [preauth]
sshd[2456]: 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 [preauth]
sshd[2456]: 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 [preauth]
sshd[2456]: 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 [preauth]
sshd[2456]: 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 [preauth]
sshd[2456]: debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 [preauth]
sshd[2456]: debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 [preauth]
sshd[2456]: debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib [preauth]
sshd[2456]: debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib [preauth]
sshd[2456]: debug2: kex_parse_kexinit: [preauth]
sshd[2456]: debug2: kex_parse_kexinit: [preauth]
sshd[2456]: debug2: kex_parse_kexinit: first_kex_follows 0 [preauth]
sshd[2456]: debug2: kex_parse_kexinit: reserved 0 [preauth]
sshd[2456]: debug2: mac_setup: found hmac-md5 [preauth]
sshd[2456]: debug1: kex: client->server aes128-ctr hmac-md5 none [preauth]
sshd[2456]: debug2: mac_setup: found hmac-md5 [preauth]
sshd[2456]: debug1: kex: server->client aes128-ctr hmac-md5 none [preauth]
sshd[2456]: debug1: expecting SSH2_MSG_KEX_ECDH_INIT [preauth]
sshd[2456]: debug3: mm_key_sign entering [preauth]
sshd[2456]: debug3: mm_request_send entering: type 5 [preauth]
sshd[2456]: debug3: mm_key_sign: waiting for MONITOR_ANS_SIGN [preauth]
sshd[2456]: debug3: mm_request_receive_expect entering: type 6 [preauth]
sshd[2456]: debug3: mm_request_receive entering [preauth]
sshd[2456]: debug3: mm_request_receive entering
sshd[2456]: debug3: monitor_read: checking request 5
sshd[2456]: debug3: mm_answer_sign
sshd[2456]: debug3: mm_answer_sign: signature 0x7f9b687c7680(100)
sshd[2456]: debug3: mm_request_send entering: type 6
sshd[2456]: debug2: monitor_read: 5 used once, disabling now
sshd[2456]: debug2: kex_derive_keys [preauth]
sshd[2456]: debug2: set_newkeys: mode 1 [preauth]
sshd[2456]: debug1: SSH2_MSG_NEWKEYS sent [preauth]
sshd[2456]: debug1: expecting SSH2_MSG_NEWKEYS [preauth]
sshd[2456]: Connection closed by 192.168.1.6 [preauth]
sshd[2456]: debug1: do_cleanup [preauth]
sshd[2456]: debug3: PAM: sshpam_thread_cleanup entering [preauth]
sshd[2456]: debug1: monitor_read_log: child log fd closed
sshd[2456]: debug3: mm_request_receive entering
sshd[2456]: debug1: do_cleanup
sshd[2456]: debug3: PAM: sshpam_thread_cleanup entering
sshd[2456]: debug1: Killing privsep child 2457
UPDATE
I tried a manual sshfs
mount and I also get read: Connection reset by peer
. I then added the debuging options and also got Permission denied (publickey).
. This is strange since the public key is in place and works fine otherwise. I also use my user for the ssh connection and manually specify the private key file. Could this be an issue with the root account not beeing able to access the correct public key on the server somewhere? I'm executing
sudo sshfs myuser@myserver:/mnt/foo /mnt/foo -o IdentityFile=/home/myuser/.ssh/id_rsa
and the relevant log part is
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/myuser/.ssh/id_rsa
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.
Permission denied (publickey).
read: Connection reset by peer
ssh sshfs
1
The output looks exactly like one from a ssh session which refuses to connect due to server key fingerprint mismatch (or an unknown key). Doessftp
to the server work correctly?
– peterph
Oct 12 '13 at 8:19
I tried sftp with both Nautilus (Connect to Server...
option) and Filezilla. It works fine. Although Filezilla asked my about an unknown host key.
– André Stannek
Oct 12 '13 at 11:09
Trysftp
directly - that is what SSHFS uses.
– peterph
Oct 12 '13 at 15:23
4
Looks the same to me. Have you tried to get some debugging info from the client?sshfs -odebug,sshfs_debug,loglevel=debug ...
could do the trick (taken from sourceforge.net/apps/mediawiki/fuse/index.php?title=SshfsFaq).
– peterph
Oct 12 '13 at 16:54
1
@peterph already got that idea ;-) See my second update. I just omitted the debug parameters in the command posted here but I executed it with them.
– André Stannek
Oct 12 '13 at 16:57
|
show 7 more comments
I am using a fuse/sshfs mount which worked fine so far. Now I had to reinstall the server system and suddenly getting the classic read: Connection reset by peer
error. I am using public key authentication and copied my key to the newly installed system. Normal ssh login works fine. I changed the log to debug but sadly this doesn't give me any useful information:
sshd[2077]: debug1: Forked child 2198.
sshd[2198]: Set /proc/self/oom_score_adj to 0
sshd[2198]: debug1: rexec start in 5 out 5 newsock 5 pipe 7 sock 8
sshd[2198]: debug1: inetd sockets after dupping: 3, 3
sshd[2198]: Connection from 192.168.1.6 port 47991
sshd[2198]: debug1: Client protocol version 2.0; client software version OpenSSH_6.1p1 Debian-4
sshd[2198]: debug1: match: OpenSSH_6.1p1 Debian-4 pat OpenSSH*
sshd[2198]: debug1: Enabling compatibility mode for protocol 2.0
sshd[2198]: debug1: Local version string SSH-2.0-OpenSSH_6.1p1 Debian-4
sshd[2198]: debug1: permanently_set_uid: 103/65534 [preauth]
sshd[2198]: debug1: list_hostkey_types: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256 [preauth]
sshd[2198]: debug1: SSH2_MSG_KEXINIT sent [preauth]
sshd[2198]: debug1: SSH2_MSG_KEXINIT received [preauth]
sshd[2198]: debug1: kex: client->server aes128-ctr hmac-md5 none [preauth]
sshd[2198]: debug1: kex: server->client aes128-ctr hmac-md5 none [preauth]
sshd[2198]: debug1: expecting SSH2_MSG_KEX_ECDH_INIT [preauth]
sshd[2198]: debug1: SSH2_MSG_NEWKEYS sent [preauth]
sshd[2198]: debug1: expecting SSH2_MSG_NEWKEYS [preauth]
sshd[2198]: Connection closed by 192.168.1.6 [preauth]
sshd[2198]: debug1: do_cleanup [preauth]
sshd[2198]: debug1: monitor_read_log: child log fd closed
sshd[2198]: debug1: do_cleanup
sshd[2198]: debug1: Killing privsep child 2199
Does anyone have an idea what I am missing here?
UPDATE
The auth.log
with debug level 3:
sshd[2455]: debug3: fd 5 is not O_NONBLOCK
sshd[2455]: debug1: Forked child 2456.
sshd[2455]: debug3: send_rexec_state: entering fd = 8 config len 751
sshd[2455]: debug3: ssh_msg_send: type 0
sshd[2455]: debug3: send_rexec_state: done
sshd[2456]: debug3: oom_adjust_restore
sshd[2456]: Set /proc/self/oom_score_adj to 0
sshd[2456]: debug1: rexec start in 5 out 5 newsock 5 pipe 7 sock 8
sshd[2456]: debug1: inetd sockets after dupping: 3, 3
sshd[2456]: Connection from 192.168.1.6 port 50037
sshd[2456]: debug1: Client protocol version 2.0; client software version OpenSSH_6.1p1 Debian-4
sshd[2456]: debug1: match: OpenSSH_6.1p1 Debian-4 pat OpenSSH*
sshd[2456]: debug1: Enabling compatibility mode for protocol 2.0
sshd[2456]: debug1: Local version string SSH-2.0-OpenSSH_6.1p1 Debian-4
sshd[2456]: debug2: fd 3 setting O_NONBLOCK
sshd[2456]: debug2: Network child is on pid 2457
sshd[2456]: debug3: preauth child monitor started
sshd[2456]: debug3: privsep user:group 103:65534 [preauth]
sshd[2456]: debug1: permanently_set_uid: 103/65534 [preauth]
sshd[2456]: debug1: list_hostkey_types: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256 [preauth]
sshd[2456]: debug1: SSH2_MSG_KEXINIT sent [preauth]
sshd[2456]: debug1: SSH2_MSG_KEXINIT received [preauth]
sshd[2456]: 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 [preauth]
sshd[2456]: debug2: kex_parse_kexinit: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256 [preauth]
sshd[2456]: 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 [preauth]
sshd[2456]: 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 [preauth]
sshd[2456]: debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 [preauth]
sshd[2456]: debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 [preauth]
sshd[2456]: debug2: kex_parse_kexinit: none,zlib@openssh.com [preauth]
sshd[2456]: debug2: kex_parse_kexinit: none,zlib@openssh.com [preauth]
sshd[2456]: debug2: kex_parse_kexinit: [preauth]
sshd[2456]: debug2: kex_parse_kexinit: [preauth]
sshd[2456]: debug2: kex_parse_kexinit: first_kex_follows 0 [preauth]
sshd[2456]: debug2: kex_parse_kexinit: reserved 0 [preauth]
sshd[2456]: 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 [preauth]
sshd[2456]: 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 [preauth]
sshd[2456]: 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 [preauth]
sshd[2456]: 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 [preauth]
sshd[2456]: debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 [preauth]
sshd[2456]: debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 [preauth]
sshd[2456]: debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib [preauth]
sshd[2456]: debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib [preauth]
sshd[2456]: debug2: kex_parse_kexinit: [preauth]
sshd[2456]: debug2: kex_parse_kexinit: [preauth]
sshd[2456]: debug2: kex_parse_kexinit: first_kex_follows 0 [preauth]
sshd[2456]: debug2: kex_parse_kexinit: reserved 0 [preauth]
sshd[2456]: debug2: mac_setup: found hmac-md5 [preauth]
sshd[2456]: debug1: kex: client->server aes128-ctr hmac-md5 none [preauth]
sshd[2456]: debug2: mac_setup: found hmac-md5 [preauth]
sshd[2456]: debug1: kex: server->client aes128-ctr hmac-md5 none [preauth]
sshd[2456]: debug1: expecting SSH2_MSG_KEX_ECDH_INIT [preauth]
sshd[2456]: debug3: mm_key_sign entering [preauth]
sshd[2456]: debug3: mm_request_send entering: type 5 [preauth]
sshd[2456]: debug3: mm_key_sign: waiting for MONITOR_ANS_SIGN [preauth]
sshd[2456]: debug3: mm_request_receive_expect entering: type 6 [preauth]
sshd[2456]: debug3: mm_request_receive entering [preauth]
sshd[2456]: debug3: mm_request_receive entering
sshd[2456]: debug3: monitor_read: checking request 5
sshd[2456]: debug3: mm_answer_sign
sshd[2456]: debug3: mm_answer_sign: signature 0x7f9b687c7680(100)
sshd[2456]: debug3: mm_request_send entering: type 6
sshd[2456]: debug2: monitor_read: 5 used once, disabling now
sshd[2456]: debug2: kex_derive_keys [preauth]
sshd[2456]: debug2: set_newkeys: mode 1 [preauth]
sshd[2456]: debug1: SSH2_MSG_NEWKEYS sent [preauth]
sshd[2456]: debug1: expecting SSH2_MSG_NEWKEYS [preauth]
sshd[2456]: Connection closed by 192.168.1.6 [preauth]
sshd[2456]: debug1: do_cleanup [preauth]
sshd[2456]: debug3: PAM: sshpam_thread_cleanup entering [preauth]
sshd[2456]: debug1: monitor_read_log: child log fd closed
sshd[2456]: debug3: mm_request_receive entering
sshd[2456]: debug1: do_cleanup
sshd[2456]: debug3: PAM: sshpam_thread_cleanup entering
sshd[2456]: debug1: Killing privsep child 2457
UPDATE
I tried a manual sshfs
mount and I also get read: Connection reset by peer
. I then added the debuging options and also got Permission denied (publickey).
. This is strange since the public key is in place and works fine otherwise. I also use my user for the ssh connection and manually specify the private key file. Could this be an issue with the root account not beeing able to access the correct public key on the server somewhere? I'm executing
sudo sshfs myuser@myserver:/mnt/foo /mnt/foo -o IdentityFile=/home/myuser/.ssh/id_rsa
and the relevant log part is
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/myuser/.ssh/id_rsa
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.
Permission denied (publickey).
read: Connection reset by peer
ssh sshfs
I am using a fuse/sshfs mount which worked fine so far. Now I had to reinstall the server system and suddenly getting the classic read: Connection reset by peer
error. I am using public key authentication and copied my key to the newly installed system. Normal ssh login works fine. I changed the log to debug but sadly this doesn't give me any useful information:
sshd[2077]: debug1: Forked child 2198.
sshd[2198]: Set /proc/self/oom_score_adj to 0
sshd[2198]: debug1: rexec start in 5 out 5 newsock 5 pipe 7 sock 8
sshd[2198]: debug1: inetd sockets after dupping: 3, 3
sshd[2198]: Connection from 192.168.1.6 port 47991
sshd[2198]: debug1: Client protocol version 2.0; client software version OpenSSH_6.1p1 Debian-4
sshd[2198]: debug1: match: OpenSSH_6.1p1 Debian-4 pat OpenSSH*
sshd[2198]: debug1: Enabling compatibility mode for protocol 2.0
sshd[2198]: debug1: Local version string SSH-2.0-OpenSSH_6.1p1 Debian-4
sshd[2198]: debug1: permanently_set_uid: 103/65534 [preauth]
sshd[2198]: debug1: list_hostkey_types: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256 [preauth]
sshd[2198]: debug1: SSH2_MSG_KEXINIT sent [preauth]
sshd[2198]: debug1: SSH2_MSG_KEXINIT received [preauth]
sshd[2198]: debug1: kex: client->server aes128-ctr hmac-md5 none [preauth]
sshd[2198]: debug1: kex: server->client aes128-ctr hmac-md5 none [preauth]
sshd[2198]: debug1: expecting SSH2_MSG_KEX_ECDH_INIT [preauth]
sshd[2198]: debug1: SSH2_MSG_NEWKEYS sent [preauth]
sshd[2198]: debug1: expecting SSH2_MSG_NEWKEYS [preauth]
sshd[2198]: Connection closed by 192.168.1.6 [preauth]
sshd[2198]: debug1: do_cleanup [preauth]
sshd[2198]: debug1: monitor_read_log: child log fd closed
sshd[2198]: debug1: do_cleanup
sshd[2198]: debug1: Killing privsep child 2199
Does anyone have an idea what I am missing here?
UPDATE
The auth.log
with debug level 3:
sshd[2455]: debug3: fd 5 is not O_NONBLOCK
sshd[2455]: debug1: Forked child 2456.
sshd[2455]: debug3: send_rexec_state: entering fd = 8 config len 751
sshd[2455]: debug3: ssh_msg_send: type 0
sshd[2455]: debug3: send_rexec_state: done
sshd[2456]: debug3: oom_adjust_restore
sshd[2456]: Set /proc/self/oom_score_adj to 0
sshd[2456]: debug1: rexec start in 5 out 5 newsock 5 pipe 7 sock 8
sshd[2456]: debug1: inetd sockets after dupping: 3, 3
sshd[2456]: Connection from 192.168.1.6 port 50037
sshd[2456]: debug1: Client protocol version 2.0; client software version OpenSSH_6.1p1 Debian-4
sshd[2456]: debug1: match: OpenSSH_6.1p1 Debian-4 pat OpenSSH*
sshd[2456]: debug1: Enabling compatibility mode for protocol 2.0
sshd[2456]: debug1: Local version string SSH-2.0-OpenSSH_6.1p1 Debian-4
sshd[2456]: debug2: fd 3 setting O_NONBLOCK
sshd[2456]: debug2: Network child is on pid 2457
sshd[2456]: debug3: preauth child monitor started
sshd[2456]: debug3: privsep user:group 103:65534 [preauth]
sshd[2456]: debug1: permanently_set_uid: 103/65534 [preauth]
sshd[2456]: debug1: list_hostkey_types: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256 [preauth]
sshd[2456]: debug1: SSH2_MSG_KEXINIT sent [preauth]
sshd[2456]: debug1: SSH2_MSG_KEXINIT received [preauth]
sshd[2456]: 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 [preauth]
sshd[2456]: debug2: kex_parse_kexinit: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256 [preauth]
sshd[2456]: 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 [preauth]
sshd[2456]: 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 [preauth]
sshd[2456]: debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 [preauth]
sshd[2456]: debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 [preauth]
sshd[2456]: debug2: kex_parse_kexinit: none,zlib@openssh.com [preauth]
sshd[2456]: debug2: kex_parse_kexinit: none,zlib@openssh.com [preauth]
sshd[2456]: debug2: kex_parse_kexinit: [preauth]
sshd[2456]: debug2: kex_parse_kexinit: [preauth]
sshd[2456]: debug2: kex_parse_kexinit: first_kex_follows 0 [preauth]
sshd[2456]: debug2: kex_parse_kexinit: reserved 0 [preauth]
sshd[2456]: 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 [preauth]
sshd[2456]: 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 [preauth]
sshd[2456]: 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 [preauth]
sshd[2456]: 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 [preauth]
sshd[2456]: debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 [preauth]
sshd[2456]: debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 [preauth]
sshd[2456]: debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib [preauth]
sshd[2456]: debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib [preauth]
sshd[2456]: debug2: kex_parse_kexinit: [preauth]
sshd[2456]: debug2: kex_parse_kexinit: [preauth]
sshd[2456]: debug2: kex_parse_kexinit: first_kex_follows 0 [preauth]
sshd[2456]: debug2: kex_parse_kexinit: reserved 0 [preauth]
sshd[2456]: debug2: mac_setup: found hmac-md5 [preauth]
sshd[2456]: debug1: kex: client->server aes128-ctr hmac-md5 none [preauth]
sshd[2456]: debug2: mac_setup: found hmac-md5 [preauth]
sshd[2456]: debug1: kex: server->client aes128-ctr hmac-md5 none [preauth]
sshd[2456]: debug1: expecting SSH2_MSG_KEX_ECDH_INIT [preauth]
sshd[2456]: debug3: mm_key_sign entering [preauth]
sshd[2456]: debug3: mm_request_send entering: type 5 [preauth]
sshd[2456]: debug3: mm_key_sign: waiting for MONITOR_ANS_SIGN [preauth]
sshd[2456]: debug3: mm_request_receive_expect entering: type 6 [preauth]
sshd[2456]: debug3: mm_request_receive entering [preauth]
sshd[2456]: debug3: mm_request_receive entering
sshd[2456]: debug3: monitor_read: checking request 5
sshd[2456]: debug3: mm_answer_sign
sshd[2456]: debug3: mm_answer_sign: signature 0x7f9b687c7680(100)
sshd[2456]: debug3: mm_request_send entering: type 6
sshd[2456]: debug2: monitor_read: 5 used once, disabling now
sshd[2456]: debug2: kex_derive_keys [preauth]
sshd[2456]: debug2: set_newkeys: mode 1 [preauth]
sshd[2456]: debug1: SSH2_MSG_NEWKEYS sent [preauth]
sshd[2456]: debug1: expecting SSH2_MSG_NEWKEYS [preauth]
sshd[2456]: Connection closed by 192.168.1.6 [preauth]
sshd[2456]: debug1: do_cleanup [preauth]
sshd[2456]: debug3: PAM: sshpam_thread_cleanup entering [preauth]
sshd[2456]: debug1: monitor_read_log: child log fd closed
sshd[2456]: debug3: mm_request_receive entering
sshd[2456]: debug1: do_cleanup
sshd[2456]: debug3: PAM: sshpam_thread_cleanup entering
sshd[2456]: debug1: Killing privsep child 2457
UPDATE
I tried a manual sshfs
mount and I also get read: Connection reset by peer
. I then added the debuging options and also got Permission denied (publickey).
. This is strange since the public key is in place and works fine otherwise. I also use my user for the ssh connection and manually specify the private key file. Could this be an issue with the root account not beeing able to access the correct public key on the server somewhere? I'm executing
sudo sshfs myuser@myserver:/mnt/foo /mnt/foo -o IdentityFile=/home/myuser/.ssh/id_rsa
and the relevant log part is
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/myuser/.ssh/id_rsa
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.
Permission denied (publickey).
read: Connection reset by peer
ssh sshfs
ssh sshfs
edited Oct 12 '13 at 18:00
asked Oct 12 '13 at 3:55
André Stannek
5031514
5031514
1
The output looks exactly like one from a ssh session which refuses to connect due to server key fingerprint mismatch (or an unknown key). Doessftp
to the server work correctly?
– peterph
Oct 12 '13 at 8:19
I tried sftp with both Nautilus (Connect to Server...
option) and Filezilla. It works fine. Although Filezilla asked my about an unknown host key.
– André Stannek
Oct 12 '13 at 11:09
Trysftp
directly - that is what SSHFS uses.
– peterph
Oct 12 '13 at 15:23
4
Looks the same to me. Have you tried to get some debugging info from the client?sshfs -odebug,sshfs_debug,loglevel=debug ...
could do the trick (taken from sourceforge.net/apps/mediawiki/fuse/index.php?title=SshfsFaq).
– peterph
Oct 12 '13 at 16:54
1
@peterph already got that idea ;-) See my second update. I just omitted the debug parameters in the command posted here but I executed it with them.
– André Stannek
Oct 12 '13 at 16:57
|
show 7 more comments
1
The output looks exactly like one from a ssh session which refuses to connect due to server key fingerprint mismatch (or an unknown key). Doessftp
to the server work correctly?
– peterph
Oct 12 '13 at 8:19
I tried sftp with both Nautilus (Connect to Server...
option) and Filezilla. It works fine. Although Filezilla asked my about an unknown host key.
– André Stannek
Oct 12 '13 at 11:09
Trysftp
directly - that is what SSHFS uses.
– peterph
Oct 12 '13 at 15:23
4
Looks the same to me. Have you tried to get some debugging info from the client?sshfs -odebug,sshfs_debug,loglevel=debug ...
could do the trick (taken from sourceforge.net/apps/mediawiki/fuse/index.php?title=SshfsFaq).
– peterph
Oct 12 '13 at 16:54
1
@peterph already got that idea ;-) See my second update. I just omitted the debug parameters in the command posted here but I executed it with them.
– André Stannek
Oct 12 '13 at 16:57
1
1
The output looks exactly like one from a ssh session which refuses to connect due to server key fingerprint mismatch (or an unknown key). Does
sftp
to the server work correctly?– peterph
Oct 12 '13 at 8:19
The output looks exactly like one from a ssh session which refuses to connect due to server key fingerprint mismatch (or an unknown key). Does
sftp
to the server work correctly?– peterph
Oct 12 '13 at 8:19
I tried sftp with both Nautilus (
Connect to Server...
option) and Filezilla. It works fine. Although Filezilla asked my about an unknown host key.– André Stannek
Oct 12 '13 at 11:09
I tried sftp with both Nautilus (
Connect to Server...
option) and Filezilla. It works fine. Although Filezilla asked my about an unknown host key.– André Stannek
Oct 12 '13 at 11:09
Try
sftp
directly - that is what SSHFS uses.– peterph
Oct 12 '13 at 15:23
Try
sftp
directly - that is what SSHFS uses.– peterph
Oct 12 '13 at 15:23
4
4
Looks the same to me. Have you tried to get some debugging info from the client?
sshfs -odebug,sshfs_debug,loglevel=debug ...
could do the trick (taken from sourceforge.net/apps/mediawiki/fuse/index.php?title=SshfsFaq).– peterph
Oct 12 '13 at 16:54
Looks the same to me. Have you tried to get some debugging info from the client?
sshfs -odebug,sshfs_debug,loglevel=debug ...
could do the trick (taken from sourceforge.net/apps/mediawiki/fuse/index.php?title=SshfsFaq).– peterph
Oct 12 '13 at 16:54
1
1
@peterph already got that idea ;-) See my second update. I just omitted the debug parameters in the command posted here but I executed it with them.
– André Stannek
Oct 12 '13 at 16:57
@peterph already got that idea ;-) See my second update. I just omitted the debug parameters in the command posted here but I executed it with them.
– André Stannek
Oct 12 '13 at 16:57
|
show 7 more comments
9 Answers
9
active
oldest
votes
After a lot more of trying it turns out my client user wasn't in the fuse
group. After I added it with sudo usermod -a -G fuse myuser
the mount works fine again. Don't ask me how it could have worked before reinstalling the server. Thank for all your help!
2
is this the user on the local or remote file system?
– Woodrow Barlow
Jan 4 '17 at 16:24
1
@WoodrowBarlow to be honest I don't know anymore :D My best guess would be local, since this is where you use fuse.
– André Stannek
Jan 4 '17 at 16:29
orgpasswd --add USER fuse
– qreba47jhqb4e3lstrujvvdx
Oct 9 '17 at 0:08
add a comment |
This is a dead question but I've also came across this issue. I was using the -F /path/to/config
option. The answer was in my config file I had:
IdentityFile ~/.ssh/id_rsa
Did not work, But the absolute path is required:
IdentityFile /home/user/.ssh/id_rsa
man ssh-config
explicitely allows tilde forIdentityFile
– CharlesB
Apr 4 at 10:39
1
@CharlesB I have tested it both ways and I assure you my answer is valid. And I do see what you're referencing in the man pages. Perhaps it's a bug when running with sudo? (because I am)
– Sanchke Dellowar
Jun 9 at 21:58
1
sure, if you're running sshfs with sudo, tilde is the home of the root user. then you need to specify absolute path.
– CharlesB
Jun 11 at 10:40
add a comment |
I found my problem, which was similar, had to do with the fuse configuration file in:
/etc/fuse.conf
I had to un-comment:
user_allow_other
add a comment |
Just in case someone stumbles over this thread: I had this read: Connection reset by peer
error because the host name was not resolvable (I was not using a fully-qualified host). Using the right host name solved the issue - the error message is just completely misleading then.
A good test is to ssh to the machine before running the sshfs command, if that does not even work sshfs will not work either.
sshfs server-ssh-alias:/some/dir /mnt didn't work for me, but sshfs real.servername.org:/some/dir /mnt did work for me. (combined with user_allow_other)
– Brian C.
Oct 4 at 19:47
add a comment |
I had the same issue today.
ssh
connection is OK, sshfs
is not.
My SSH server is Qnap NAS (TS-228).
The problem was fixed by enabling SFTP on NAS device.
Additional setting appeared in sshd_config
:
Subsystem sftp /usr/libexec/sftp-server
1
There is already a solution to this question.
– RalfFriedl
Aug 19 at 21:59
add a comment |
Since this error message is the default one when ssh connection fails, the most generic answer (per @peterph comment) is to investigate using at least -odebug
:
sshfs -odebug,sshfs_debug,loglevel=debug ...
for example
sshfs -odebug,sshfs_debug,loglevel=debug -o Ciphers=arcfour -o Compression=no -o allow_root -o transform_symlinks localhost:/ /mnt/your_mount_point
As said elsewhere, common causes include missing allow_other
in fuse.conf
or missing fuse
group membership (although that may not be needed anymore on Ubuntu 18.04?)
In my case this printed:
SSHFS version 2.8
FUSE library version: 2.9.7
nullpath_ok: 0
nopath: 0
utime_omit_ok: 0
executing <ssh> <-x> <-a> <-oClearAllForwardings=yes> <-ologlevel=debug> <-oIdentityFile=~/.ssh/id_rsa> <-oCiphers=arcfour> <-oCompression=no> <-2> <localhost> <-s> <sftp>
command-line line 0: Bad SSH2 cipher spec 'arcfour'.
read: Connection reset by peer
...pointing to an unsupported Cipher option (working on fedora but not ubuntu)
add a comment |
I erased the host's fingerprint from /home/user/.ssh/known_hosts (actually deleted the whole file) and it fixed it... because the fingerprint had changed. using ssh to connect to the host gave a clear reason of why it was not connecting.
add a comment |
I had a similar issue, and when I checked the network config, system some how lost the gateway address. So I ran the below command
route add default gw 192.169.0.254
and then rebooted the system.
Issue is resolved after the reboot. Hope it helps someone.
1
You got "connection reset by peer" with a bad gateway?!?
– Jeff Schaller
Jan 15 at 0:54
add a comment |
I got this error and tried the methods above and failed at making it work.
The problem was the server was not accepting ssh at port 22. I used:
$sshfs -p 2222 user@server:/path/to/folder ~/local/path
and it solved the issue.
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f94720%2fconnection-reset-by-peer-using-sshfs%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
9 Answers
9
active
oldest
votes
9 Answers
9
active
oldest
votes
active
oldest
votes
active
oldest
votes
After a lot more of trying it turns out my client user wasn't in the fuse
group. After I added it with sudo usermod -a -G fuse myuser
the mount works fine again. Don't ask me how it could have worked before reinstalling the server. Thank for all your help!
2
is this the user on the local or remote file system?
– Woodrow Barlow
Jan 4 '17 at 16:24
1
@WoodrowBarlow to be honest I don't know anymore :D My best guess would be local, since this is where you use fuse.
– André Stannek
Jan 4 '17 at 16:29
orgpasswd --add USER fuse
– qreba47jhqb4e3lstrujvvdx
Oct 9 '17 at 0:08
add a comment |
After a lot more of trying it turns out my client user wasn't in the fuse
group. After I added it with sudo usermod -a -G fuse myuser
the mount works fine again. Don't ask me how it could have worked before reinstalling the server. Thank for all your help!
2
is this the user on the local or remote file system?
– Woodrow Barlow
Jan 4 '17 at 16:24
1
@WoodrowBarlow to be honest I don't know anymore :D My best guess would be local, since this is where you use fuse.
– André Stannek
Jan 4 '17 at 16:29
orgpasswd --add USER fuse
– qreba47jhqb4e3lstrujvvdx
Oct 9 '17 at 0:08
add a comment |
After a lot more of trying it turns out my client user wasn't in the fuse
group. After I added it with sudo usermod -a -G fuse myuser
the mount works fine again. Don't ask me how it could have worked before reinstalling the server. Thank for all your help!
After a lot more of trying it turns out my client user wasn't in the fuse
group. After I added it with sudo usermod -a -G fuse myuser
the mount works fine again. Don't ask me how it could have worked before reinstalling the server. Thank for all your help!
answered Oct 21 '13 at 8:27
André Stannek
5031514
5031514
2
is this the user on the local or remote file system?
– Woodrow Barlow
Jan 4 '17 at 16:24
1
@WoodrowBarlow to be honest I don't know anymore :D My best guess would be local, since this is where you use fuse.
– André Stannek
Jan 4 '17 at 16:29
orgpasswd --add USER fuse
– qreba47jhqb4e3lstrujvvdx
Oct 9 '17 at 0:08
add a comment |
2
is this the user on the local or remote file system?
– Woodrow Barlow
Jan 4 '17 at 16:24
1
@WoodrowBarlow to be honest I don't know anymore :D My best guess would be local, since this is where you use fuse.
– André Stannek
Jan 4 '17 at 16:29
orgpasswd --add USER fuse
– qreba47jhqb4e3lstrujvvdx
Oct 9 '17 at 0:08
2
2
is this the user on the local or remote file system?
– Woodrow Barlow
Jan 4 '17 at 16:24
is this the user on the local or remote file system?
– Woodrow Barlow
Jan 4 '17 at 16:24
1
1
@WoodrowBarlow to be honest I don't know anymore :D My best guess would be local, since this is where you use fuse.
– André Stannek
Jan 4 '17 at 16:29
@WoodrowBarlow to be honest I don't know anymore :D My best guess would be local, since this is where you use fuse.
– André Stannek
Jan 4 '17 at 16:29
or
gpasswd --add USER fuse
– qreba47jhqb4e3lstrujvvdx
Oct 9 '17 at 0:08
or
gpasswd --add USER fuse
– qreba47jhqb4e3lstrujvvdx
Oct 9 '17 at 0:08
add a comment |
This is a dead question but I've also came across this issue. I was using the -F /path/to/config
option. The answer was in my config file I had:
IdentityFile ~/.ssh/id_rsa
Did not work, But the absolute path is required:
IdentityFile /home/user/.ssh/id_rsa
man ssh-config
explicitely allows tilde forIdentityFile
– CharlesB
Apr 4 at 10:39
1
@CharlesB I have tested it both ways and I assure you my answer is valid. And I do see what you're referencing in the man pages. Perhaps it's a bug when running with sudo? (because I am)
– Sanchke Dellowar
Jun 9 at 21:58
1
sure, if you're running sshfs with sudo, tilde is the home of the root user. then you need to specify absolute path.
– CharlesB
Jun 11 at 10:40
add a comment |
This is a dead question but I've also came across this issue. I was using the -F /path/to/config
option. The answer was in my config file I had:
IdentityFile ~/.ssh/id_rsa
Did not work, But the absolute path is required:
IdentityFile /home/user/.ssh/id_rsa
man ssh-config
explicitely allows tilde forIdentityFile
– CharlesB
Apr 4 at 10:39
1
@CharlesB I have tested it both ways and I assure you my answer is valid. And I do see what you're referencing in the man pages. Perhaps it's a bug when running with sudo? (because I am)
– Sanchke Dellowar
Jun 9 at 21:58
1
sure, if you're running sshfs with sudo, tilde is the home of the root user. then you need to specify absolute path.
– CharlesB
Jun 11 at 10:40
add a comment |
This is a dead question but I've also came across this issue. I was using the -F /path/to/config
option. The answer was in my config file I had:
IdentityFile ~/.ssh/id_rsa
Did not work, But the absolute path is required:
IdentityFile /home/user/.ssh/id_rsa
This is a dead question but I've also came across this issue. I was using the -F /path/to/config
option. The answer was in my config file I had:
IdentityFile ~/.ssh/id_rsa
Did not work, But the absolute path is required:
IdentityFile /home/user/.ssh/id_rsa
answered Mar 29 at 1:38
Sanchke Dellowar
16816
16816
man ssh-config
explicitely allows tilde forIdentityFile
– CharlesB
Apr 4 at 10:39
1
@CharlesB I have tested it both ways and I assure you my answer is valid. And I do see what you're referencing in the man pages. Perhaps it's a bug when running with sudo? (because I am)
– Sanchke Dellowar
Jun 9 at 21:58
1
sure, if you're running sshfs with sudo, tilde is the home of the root user. then you need to specify absolute path.
– CharlesB
Jun 11 at 10:40
add a comment |
man ssh-config
explicitely allows tilde forIdentityFile
– CharlesB
Apr 4 at 10:39
1
@CharlesB I have tested it both ways and I assure you my answer is valid. And I do see what you're referencing in the man pages. Perhaps it's a bug when running with sudo? (because I am)
– Sanchke Dellowar
Jun 9 at 21:58
1
sure, if you're running sshfs with sudo, tilde is the home of the root user. then you need to specify absolute path.
– CharlesB
Jun 11 at 10:40
man ssh-config
explicitely allows tilde for IdentityFile
– CharlesB
Apr 4 at 10:39
man ssh-config
explicitely allows tilde for IdentityFile
– CharlesB
Apr 4 at 10:39
1
1
@CharlesB I have tested it both ways and I assure you my answer is valid. And I do see what you're referencing in the man pages. Perhaps it's a bug when running with sudo? (because I am)
– Sanchke Dellowar
Jun 9 at 21:58
@CharlesB I have tested it both ways and I assure you my answer is valid. And I do see what you're referencing in the man pages. Perhaps it's a bug when running with sudo? (because I am)
– Sanchke Dellowar
Jun 9 at 21:58
1
1
sure, if you're running sshfs with sudo, tilde is the home of the root user. then you need to specify absolute path.
– CharlesB
Jun 11 at 10:40
sure, if you're running sshfs with sudo, tilde is the home of the root user. then you need to specify absolute path.
– CharlesB
Jun 11 at 10:40
add a comment |
I found my problem, which was similar, had to do with the fuse configuration file in:
/etc/fuse.conf
I had to un-comment:
user_allow_other
add a comment |
I found my problem, which was similar, had to do with the fuse configuration file in:
/etc/fuse.conf
I had to un-comment:
user_allow_other
add a comment |
I found my problem, which was similar, had to do with the fuse configuration file in:
/etc/fuse.conf
I had to un-comment:
user_allow_other
I found my problem, which was similar, had to do with the fuse configuration file in:
/etc/fuse.conf
I had to un-comment:
user_allow_other
edited Mar 26 '17 at 16:55
Stephen Rauch
3,328101328
3,328101328
answered Mar 26 '17 at 15:35
cennings
411
411
add a comment |
add a comment |
Just in case someone stumbles over this thread: I had this read: Connection reset by peer
error because the host name was not resolvable (I was not using a fully-qualified host). Using the right host name solved the issue - the error message is just completely misleading then.
A good test is to ssh to the machine before running the sshfs command, if that does not even work sshfs will not work either.
sshfs server-ssh-alias:/some/dir /mnt didn't work for me, but sshfs real.servername.org:/some/dir /mnt did work for me. (combined with user_allow_other)
– Brian C.
Oct 4 at 19:47
add a comment |
Just in case someone stumbles over this thread: I had this read: Connection reset by peer
error because the host name was not resolvable (I was not using a fully-qualified host). Using the right host name solved the issue - the error message is just completely misleading then.
A good test is to ssh to the machine before running the sshfs command, if that does not even work sshfs will not work either.
sshfs server-ssh-alias:/some/dir /mnt didn't work for me, but sshfs real.servername.org:/some/dir /mnt did work for me. (combined with user_allow_other)
– Brian C.
Oct 4 at 19:47
add a comment |
Just in case someone stumbles over this thread: I had this read: Connection reset by peer
error because the host name was not resolvable (I was not using a fully-qualified host). Using the right host name solved the issue - the error message is just completely misleading then.
A good test is to ssh to the machine before running the sshfs command, if that does not even work sshfs will not work either.
Just in case someone stumbles over this thread: I had this read: Connection reset by peer
error because the host name was not resolvable (I was not using a fully-qualified host). Using the right host name solved the issue - the error message is just completely misleading then.
A good test is to ssh to the machine before running the sshfs command, if that does not even work sshfs will not work either.
edited Apr 12 at 9:17
Yurij Goncharuk
2,3232521
2,3232521
answered Apr 12 at 8:26
Bob Lauer
311
311
sshfs server-ssh-alias:/some/dir /mnt didn't work for me, but sshfs real.servername.org:/some/dir /mnt did work for me. (combined with user_allow_other)
– Brian C.
Oct 4 at 19:47
add a comment |
sshfs server-ssh-alias:/some/dir /mnt didn't work for me, but sshfs real.servername.org:/some/dir /mnt did work for me. (combined with user_allow_other)
– Brian C.
Oct 4 at 19:47
sshfs server-ssh-alias:/some/dir /mnt didn't work for me, but sshfs real.servername.org:/some/dir /mnt did work for me. (combined with user_allow_other)
– Brian C.
Oct 4 at 19:47
sshfs server-ssh-alias:/some/dir /mnt didn't work for me, but sshfs real.servername.org:/some/dir /mnt did work for me. (combined with user_allow_other)
– Brian C.
Oct 4 at 19:47
add a comment |
I had the same issue today.
ssh
connection is OK, sshfs
is not.
My SSH server is Qnap NAS (TS-228).
The problem was fixed by enabling SFTP on NAS device.
Additional setting appeared in sshd_config
:
Subsystem sftp /usr/libexec/sftp-server
1
There is already a solution to this question.
– RalfFriedl
Aug 19 at 21:59
add a comment |
I had the same issue today.
ssh
connection is OK, sshfs
is not.
My SSH server is Qnap NAS (TS-228).
The problem was fixed by enabling SFTP on NAS device.
Additional setting appeared in sshd_config
:
Subsystem sftp /usr/libexec/sftp-server
1
There is already a solution to this question.
– RalfFriedl
Aug 19 at 21:59
add a comment |
I had the same issue today.
ssh
connection is OK, sshfs
is not.
My SSH server is Qnap NAS (TS-228).
The problem was fixed by enabling SFTP on NAS device.
Additional setting appeared in sshd_config
:
Subsystem sftp /usr/libexec/sftp-server
I had the same issue today.
ssh
connection is OK, sshfs
is not.
My SSH server is Qnap NAS (TS-228).
The problem was fixed by enabling SFTP on NAS device.
Additional setting appeared in sshd_config
:
Subsystem sftp /usr/libexec/sftp-server
answered Aug 19 at 21:48
Geom
112
112
1
There is already a solution to this question.
– RalfFriedl
Aug 19 at 21:59
add a comment |
1
There is already a solution to this question.
– RalfFriedl
Aug 19 at 21:59
1
1
There is already a solution to this question.
– RalfFriedl
Aug 19 at 21:59
There is already a solution to this question.
– RalfFriedl
Aug 19 at 21:59
add a comment |
Since this error message is the default one when ssh connection fails, the most generic answer (per @peterph comment) is to investigate using at least -odebug
:
sshfs -odebug,sshfs_debug,loglevel=debug ...
for example
sshfs -odebug,sshfs_debug,loglevel=debug -o Ciphers=arcfour -o Compression=no -o allow_root -o transform_symlinks localhost:/ /mnt/your_mount_point
As said elsewhere, common causes include missing allow_other
in fuse.conf
or missing fuse
group membership (although that may not be needed anymore on Ubuntu 18.04?)
In my case this printed:
SSHFS version 2.8
FUSE library version: 2.9.7
nullpath_ok: 0
nopath: 0
utime_omit_ok: 0
executing <ssh> <-x> <-a> <-oClearAllForwardings=yes> <-ologlevel=debug> <-oIdentityFile=~/.ssh/id_rsa> <-oCiphers=arcfour> <-oCompression=no> <-2> <localhost> <-s> <sftp>
command-line line 0: Bad SSH2 cipher spec 'arcfour'.
read: Connection reset by peer
...pointing to an unsupported Cipher option (working on fedora but not ubuntu)
add a comment |
Since this error message is the default one when ssh connection fails, the most generic answer (per @peterph comment) is to investigate using at least -odebug
:
sshfs -odebug,sshfs_debug,loglevel=debug ...
for example
sshfs -odebug,sshfs_debug,loglevel=debug -o Ciphers=arcfour -o Compression=no -o allow_root -o transform_symlinks localhost:/ /mnt/your_mount_point
As said elsewhere, common causes include missing allow_other
in fuse.conf
or missing fuse
group membership (although that may not be needed anymore on Ubuntu 18.04?)
In my case this printed:
SSHFS version 2.8
FUSE library version: 2.9.7
nullpath_ok: 0
nopath: 0
utime_omit_ok: 0
executing <ssh> <-x> <-a> <-oClearAllForwardings=yes> <-ologlevel=debug> <-oIdentityFile=~/.ssh/id_rsa> <-oCiphers=arcfour> <-oCompression=no> <-2> <localhost> <-s> <sftp>
command-line line 0: Bad SSH2 cipher spec 'arcfour'.
read: Connection reset by peer
...pointing to an unsupported Cipher option (working on fedora but not ubuntu)
add a comment |
Since this error message is the default one when ssh connection fails, the most generic answer (per @peterph comment) is to investigate using at least -odebug
:
sshfs -odebug,sshfs_debug,loglevel=debug ...
for example
sshfs -odebug,sshfs_debug,loglevel=debug -o Ciphers=arcfour -o Compression=no -o allow_root -o transform_symlinks localhost:/ /mnt/your_mount_point
As said elsewhere, common causes include missing allow_other
in fuse.conf
or missing fuse
group membership (although that may not be needed anymore on Ubuntu 18.04?)
In my case this printed:
SSHFS version 2.8
FUSE library version: 2.9.7
nullpath_ok: 0
nopath: 0
utime_omit_ok: 0
executing <ssh> <-x> <-a> <-oClearAllForwardings=yes> <-ologlevel=debug> <-oIdentityFile=~/.ssh/id_rsa> <-oCiphers=arcfour> <-oCompression=no> <-2> <localhost> <-s> <sftp>
command-line line 0: Bad SSH2 cipher spec 'arcfour'.
read: Connection reset by peer
...pointing to an unsupported Cipher option (working on fedora but not ubuntu)
Since this error message is the default one when ssh connection fails, the most generic answer (per @peterph comment) is to investigate using at least -odebug
:
sshfs -odebug,sshfs_debug,loglevel=debug ...
for example
sshfs -odebug,sshfs_debug,loglevel=debug -o Ciphers=arcfour -o Compression=no -o allow_root -o transform_symlinks localhost:/ /mnt/your_mount_point
As said elsewhere, common causes include missing allow_other
in fuse.conf
or missing fuse
group membership (although that may not be needed anymore on Ubuntu 18.04?)
In my case this printed:
SSHFS version 2.8
FUSE library version: 2.9.7
nullpath_ok: 0
nopath: 0
utime_omit_ok: 0
executing <ssh> <-x> <-a> <-oClearAllForwardings=yes> <-ologlevel=debug> <-oIdentityFile=~/.ssh/id_rsa> <-oCiphers=arcfour> <-oCompression=no> <-2> <localhost> <-s> <sftp>
command-line line 0: Bad SSH2 cipher spec 'arcfour'.
read: Connection reset by peer
...pointing to an unsupported Cipher option (working on fedora but not ubuntu)
answered Sep 27 at 12:47
eddygeek
38125
38125
add a comment |
add a comment |
I erased the host's fingerprint from /home/user/.ssh/known_hosts (actually deleted the whole file) and it fixed it... because the fingerprint had changed. using ssh to connect to the host gave a clear reason of why it was not connecting.
add a comment |
I erased the host's fingerprint from /home/user/.ssh/known_hosts (actually deleted the whole file) and it fixed it... because the fingerprint had changed. using ssh to connect to the host gave a clear reason of why it was not connecting.
add a comment |
I erased the host's fingerprint from /home/user/.ssh/known_hosts (actually deleted the whole file) and it fixed it... because the fingerprint had changed. using ssh to connect to the host gave a clear reason of why it was not connecting.
I erased the host's fingerprint from /home/user/.ssh/known_hosts (actually deleted the whole file) and it fixed it... because the fingerprint had changed. using ssh to connect to the host gave a clear reason of why it was not connecting.
answered Dec 14 at 4:20
mdxe
1
1
add a comment |
add a comment |
I had a similar issue, and when I checked the network config, system some how lost the gateway address. So I ran the below command
route add default gw 192.169.0.254
and then rebooted the system.
Issue is resolved after the reboot. Hope it helps someone.
1
You got "connection reset by peer" with a bad gateway?!?
– Jeff Schaller
Jan 15 at 0:54
add a comment |
I had a similar issue, and when I checked the network config, system some how lost the gateway address. So I ran the below command
route add default gw 192.169.0.254
and then rebooted the system.
Issue is resolved after the reboot. Hope it helps someone.
1
You got "connection reset by peer" with a bad gateway?!?
– Jeff Schaller
Jan 15 at 0:54
add a comment |
I had a similar issue, and when I checked the network config, system some how lost the gateway address. So I ran the below command
route add default gw 192.169.0.254
and then rebooted the system.
Issue is resolved after the reboot. Hope it helps someone.
I had a similar issue, and when I checked the network config, system some how lost the gateway address. So I ran the below command
route add default gw 192.169.0.254
and then rebooted the system.
Issue is resolved after the reboot. Hope it helps someone.
answered Jan 14 at 23:56
Jag
1
1
1
You got "connection reset by peer" with a bad gateway?!?
– Jeff Schaller
Jan 15 at 0:54
add a comment |
1
You got "connection reset by peer" with a bad gateway?!?
– Jeff Schaller
Jan 15 at 0:54
1
1
You got "connection reset by peer" with a bad gateway?!?
– Jeff Schaller
Jan 15 at 0:54
You got "connection reset by peer" with a bad gateway?!?
– Jeff Schaller
Jan 15 at 0:54
add a comment |
I got this error and tried the methods above and failed at making it work.
The problem was the server was not accepting ssh at port 22. I used:
$sshfs -p 2222 user@server:/path/to/folder ~/local/path
and it solved the issue.
add a comment |
I got this error and tried the methods above and failed at making it work.
The problem was the server was not accepting ssh at port 22. I used:
$sshfs -p 2222 user@server:/path/to/folder ~/local/path
and it solved the issue.
add a comment |
I got this error and tried the methods above and failed at making it work.
The problem was the server was not accepting ssh at port 22. I used:
$sshfs -p 2222 user@server:/path/to/folder ~/local/path
and it solved the issue.
I got this error and tried the methods above and failed at making it work.
The problem was the server was not accepting ssh at port 22. I used:
$sshfs -p 2222 user@server:/path/to/folder ~/local/path
and it solved the issue.
answered Dec 17 at 21:26
Arashr
1
1
add a comment |
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f94720%2fconnection-reset-by-peer-using-sshfs%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
The output looks exactly like one from a ssh session which refuses to connect due to server key fingerprint mismatch (or an unknown key). Does
sftp
to the server work correctly?– peterph
Oct 12 '13 at 8:19
I tried sftp with both Nautilus (
Connect to Server...
option) and Filezilla. It works fine. Although Filezilla asked my about an unknown host key.– André Stannek
Oct 12 '13 at 11:09
Try
sftp
directly - that is what SSHFS uses.– peterph
Oct 12 '13 at 15:23
4
Looks the same to me. Have you tried to get some debugging info from the client?
sshfs -odebug,sshfs_debug,loglevel=debug ...
could do the trick (taken from sourceforge.net/apps/mediawiki/fuse/index.php?title=SshfsFaq).– peterph
Oct 12 '13 at 16:54
1
@peterph already got that idea ;-) See my second update. I just omitted the debug parameters in the command posted here but I executed it with them.
– André Stannek
Oct 12 '13 at 16:57