Connection reset by peer using sshfs












18














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









share|improve this question




















  • 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


















18














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









share|improve this question




















  • 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
















18












18








18


2





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









share|improve this question















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






share|improve this question















share|improve this question













share|improve this question




share|improve this question








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). 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
















  • 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










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












9 Answers
9






active

oldest

votes


















11














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!






share|improve this answer

















  • 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










  • or gpasswd --add USER fuse
    – qreba47jhqb4e3lstrujvvdx
    Oct 9 '17 at 0:08





















6














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





share|improve this answer





















  • man ssh-config explicitely allows tilde for IdentityFile
    – 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



















4














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





share|improve this answer































    3














    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.






    share|improve this answer























    • 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



















    1














    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





    share|improve this answer

















    • 1




      There is already a solution to this question.
      – RalfFriedl
      Aug 19 at 21:59



















    0














    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)






    share|improve this answer





























      0














      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.






      share|improve this answer





























        -1














        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.






        share|improve this answer

















        • 1




          You got "connection reset by peer" with a bad gateway?!?
          – Jeff Schaller
          Jan 15 at 0:54



















        -1














        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.






        share|improve this answer





















          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
          });


          }
          });














          draft saved

          draft discarded


















          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









          11














          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!






          share|improve this answer

















          • 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










          • or gpasswd --add USER fuse
            – qreba47jhqb4e3lstrujvvdx
            Oct 9 '17 at 0:08


















          11














          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!






          share|improve this answer

















          • 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










          • or gpasswd --add USER fuse
            – qreba47jhqb4e3lstrujvvdx
            Oct 9 '17 at 0:08
















          11












          11








          11






          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!






          share|improve this answer












          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!







          share|improve this answer












          share|improve this answer



          share|improve this answer










          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










          • or gpasswd --add USER fuse
            – qreba47jhqb4e3lstrujvvdx
            Oct 9 '17 at 0:08
















          • 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










          • or gpasswd --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















          6














          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





          share|improve this answer





















          • man ssh-config explicitely allows tilde for IdentityFile
            – 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
















          6














          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





          share|improve this answer





















          • man ssh-config explicitely allows tilde for IdentityFile
            – 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














          6












          6








          6






          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





          share|improve this answer












          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






          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Mar 29 at 1:38









          Sanchke Dellowar

          16816




          16816












          • man ssh-config explicitely allows tilde for IdentityFile
            – 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






          • 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











          4














          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





          share|improve this answer




























            4














            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





            share|improve this answer


























              4












              4








              4






              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





              share|improve this answer














              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






              share|improve this answer














              share|improve this answer



              share|improve this answer








              edited Mar 26 '17 at 16:55









              Stephen Rauch

              3,328101328




              3,328101328










              answered Mar 26 '17 at 15:35









              cennings

              411




              411























                  3














                  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.






                  share|improve this answer























                  • 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
















                  3














                  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.






                  share|improve this answer























                  • 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














                  3












                  3








                  3






                  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.






                  share|improve this answer














                  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.







                  share|improve this answer














                  share|improve this answer



                  share|improve this answer








                  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


















                  • 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











                  1














                  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





                  share|improve this answer

















                  • 1




                    There is already a solution to this question.
                    – RalfFriedl
                    Aug 19 at 21:59
















                  1














                  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





                  share|improve this answer

















                  • 1




                    There is already a solution to this question.
                    – RalfFriedl
                    Aug 19 at 21:59














                  1












                  1








                  1






                  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





                  share|improve this answer












                  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






                  share|improve this answer












                  share|improve this answer



                  share|improve this answer










                  answered Aug 19 at 21:48









                  Geom

                  112




                  112








                  • 1




                    There is already a solution to this question.
                    – RalfFriedl
                    Aug 19 at 21:59














                  • 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











                  0














                  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)






                  share|improve this answer


























                    0














                    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)






                    share|improve this answer
























                      0












                      0








                      0






                      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)






                      share|improve this answer












                      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)







                      share|improve this answer












                      share|improve this answer



                      share|improve this answer










                      answered Sep 27 at 12:47









                      eddygeek

                      38125




                      38125























                          0














                          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.






                          share|improve this answer


























                            0














                            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.






                            share|improve this answer
























                              0












                              0








                              0






                              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.






                              share|improve this answer












                              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.







                              share|improve this answer












                              share|improve this answer



                              share|improve this answer










                              answered Dec 14 at 4:20









                              mdxe

                              1




                              1























                                  -1














                                  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.






                                  share|improve this answer

















                                  • 1




                                    You got "connection reset by peer" with a bad gateway?!?
                                    – Jeff Schaller
                                    Jan 15 at 0:54
















                                  -1














                                  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.






                                  share|improve this answer

















                                  • 1




                                    You got "connection reset by peer" with a bad gateway?!?
                                    – Jeff Schaller
                                    Jan 15 at 0:54














                                  -1












                                  -1








                                  -1






                                  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.






                                  share|improve this answer












                                  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.







                                  share|improve this answer












                                  share|improve this answer



                                  share|improve this answer










                                  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














                                  • 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











                                  -1














                                  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.






                                  share|improve this answer


























                                    -1














                                    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.






                                    share|improve this answer
























                                      -1












                                      -1








                                      -1






                                      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.






                                      share|improve this answer












                                      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.







                                      share|improve this answer












                                      share|improve this answer



                                      share|improve this answer










                                      answered Dec 17 at 21:26









                                      Arashr

                                      1




                                      1






























                                          draft saved

                                          draft discarded




















































                                          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.




                                          draft saved


                                          draft discarded














                                          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





















































                                          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







                                          Popular posts from this blog

                                          Morgemoulin

                                          Scott Moir

                                          Souastre