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,<a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="ef9d8685818b8e8a83c28c8d8caf83969c8e9b809dc183869ac19c8a">[email protected]</a> [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,<a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="0b796261656f6a6e67266869684b6772786a7f64792567627e25786e">[email protected]</a> [preauth] sshd[2456]: debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,<a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="3f4a525e5c12090b7f504f5a514c4c57115c5052">[email protected]</a>,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,<a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="a5cdc8c4c688d7ccd5c0c8c1949395e5cad5c0cbd6d6cd8bc6cac8">[email protected]</a>,hmac-sha1-96,hmac-md5-96 [preauth] sshd[2456]: debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,<a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="87f2eae6e4aab1b3c7e8f7e2e9f4f4efa9e4e8ea">[email protected]</a>,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,<a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="224a4f43410f504b52474f46131412624d52474c51514a0c414d4f">[email protected]</a>,hmac-sha1-96,hmac-md5-96 [preauth] sshd[2456]: debug2: kex_parse_kexinit: none,<a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="b7cddbded5f7d8c7d2d9c4c4df99d4d8da">[email protected]</a> [preauth] sshd[2456]: debug2: kex_parse_kexinit: none,<a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="86fceaefe4c6e9f6e3e8f5f5eea8e5e9eb">[email protected]</a> [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: <a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="f09593948391dd839891c2dd9e99838480c2c5c6dd93958284dd86c0c1b09f80959e838398de939f9d">[email protected]</a>,<a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="4d282e293e2c603e252c7f6023243e393d7e7579602e283f39603b7d7c0d223d28233e3e25632e2220">[email protected]</a>,<a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="95f0f6f1e6f4b8e6fdf4a7b8fbfce6e1e5a0a7a4b8f6f0e7e1b8e3a5a4d5fae5f0fbe6e6fdbbf6faf8">[email protected]</a>,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,<a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="d0a3a3b8fda2a3b1fdb3b5a2a4fda6e0e190bfa0b5bea3a3b8feb3bfbd">[email protected]</a>,<a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="b6c5c5de9bd2c5c59bd5d3c4c29bc08687f6d9c6d3d8c5c5de98d5d9db">[email protected]</a>,<a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="790a0a11540b0a18541a1c0b0d540f49493916091c170a0a11571a1614">[email protected]</a>,<a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="88fbfbe0a5ecfbfba5ebedfafca5feb8b8c8e7f8ede6fbfbe0a6ebe7e5">[email protected]</a>,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,<a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="0e7c6764606a6f6b62236d6c6d4e62777d6f7a617c2062677b207d6b">[email protected]</a> [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,<a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="a5d7cccfcbc1c4c0c988c6c7c6e5c9dcd6c4d1cad78bc9ccd08bd6c0">[email protected]</a> [preauth] sshd[2456]: debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,<a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="daafb7bbb9f7ecee9ab5aabfb4a9a9b2f4b9b5b7">[email protected]</a>,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,<a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="40282d21236d322930252d24717670002f30252e3333286e232f2d">[email protected]</a>,hmac-sha1-96,hmac-md5-96 [preauth] sshd[2456]: debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,<a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="b4c1d9d5d7998280f4dbc4d1dac7c7dc9ad7dbd9">[email protected]</a>,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,<a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="741c19151759061d04111910454244341b04111a07071c5a171b19">[email protected]</a>,hmac-sha1-96,hmac-md5-96 [preauth] sshd[2456]: debug2: kex_parse_kexinit: none,<a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="86fceaefe4c6e9f6e3e8f5f5eea8e5e9eb">[email protected]</a>,zlib [preauth] sshd[2456]: debug2: kex_parse_kexinit: none,<a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="bdc7d1d4dffdd2cdd8d3ceced593ded2d0">[email protected]</a>,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 <a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="5e33272b2d3b2c1e33272d3b2c283b2c">[email protected]</a>:/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
Answers:
Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.
Method 1
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)
Method 2
I was using the -F /path/to/config option. The answer was in my config file where I had
IdentityFile ~/.ssh/id_rsa
which did not work. The absolute path is required:
IdentityFile /home/user/.ssh/id_rsa
Method 3
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!
Method 4
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
Method 5
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.
Method 6
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
Method 7
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 <a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="334640564173405641455641">[email protected]</a>:/path/to/folder ~/local/path
and it solved the issue.
Method 8
My error was serverside. The sftp subsystem for sshd is apparently defaulted to not available on newer centos 7.6.xx . fixed by removing “#” from in front of the following in /etc/ssh/sshd_config
Subsystem sftp /usr/libexec/openssh/sftp-server
thanks to eddygeek for the -odebug recipe to help finding this issue.
Same as GEOM above but not specific to Qnap.
Method 9
Got the same error while running sudo sshfs [...] myhost: /mnt/myhost, where myhost is defined in my ~/.ssh/config files.
The problem is that running sudo sshfs didn’t look in my home directory for ~/.ssh/config, but in roots. The solution was to pass explicitly the config file via -F:
sudo sshfs -F /home/dandv/.ssh/config [...] myhost: /mnt/myhost
Method 10
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.
Method 11
For those who are looking for a very simple solution:
After running sshfs in debug mode, I found that my connection was broken.
Turn on verbose mode with switch:
-o debug
Method 12
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.
Method 13
In my case it was the server interface not being up after a long time on startup. The server is connected to a Cisco switch port with trunk mode. Since any trunk port will do various checks before actually become UP (usually more than 30 seconds), this has resulted in the above connection reset error message.
My solution was to change the switch port to access mode with spanning-tree portfast, since in my environment the trunk mode is unnecessary for this server.
I also found out about this issue using the debugging parameter to sshfs.
Method 14
If anyone was still having issues and is an idiot like me, make sure you didn’t create the new directory (on your local system) using sudo.
Because then you, (the local user), won’t have write access to it.
Which makes it impossible to use as a mount point.
Quick fix for this is sudo chown -R localuser:localuser ~/directory_you_created
(Swap out localuser with your actual username).
Cheers.
Method 15
I found that if I tried to contact the same server with normal ssh, it gave me this: 
Which for me was accurate; it had changed.
It informed me that I could resolve that with this command:
ssh-keygen -f "/path/to/known_hosts" -R REMOTE_IP
After doing that, and running sshfs again, it worked just fine.
Method 16
I also had this problem, and I comment on the solution in case it works for someone else.
I was trying to mount a NAS on a raspberry. On the NAS I use SSH on port 2222, while SFTP goes on port 22.
I was able to find the error using the command from a previous comment:
sshfs -p 2222 -odebug,sshfs_debug,loglevel=debug -o Compression=no -o allow_root -o transform_symlinks <a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="483d3b2d3a082138">[email protected]</a>:/ /mnt/folder ................ debug1: client_input_global_request: rtype <a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="bfd7d0cccbd4dac6cc928f8fffd0cfdad1ccccd791dcd0d2">[email protected]</a> want_reply 0 debug1: Sending environment. debug1: Sending env LANG = en_US.UTF-8 debug1: Sending subsystem: sftp subsystem request failed on channel 0 read: Connection reset by peer
My mistake was that I was trying to mount via SSH port 2222, when I simply had to leave default 22 for SFTP.
sshfs <a href="https://getridbug.com/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="5227213720123b22">[email protected]</a>:/ /mnt/folder
So simple and so functional.
Method 17
I had this problem which was caused by DNS.
Ping and ssh directly worked, but
sshfs -o debug <hostname>:/ /mnt/<directory> SSHFS version 3.7.0 executing <ssh> <-x> <-a> <-oClearAllForwardings=yes> <-2> <hardie.isode.net> <-s> <sftp> ssh: Could not resolve hostname hardie.isode.net: Name or service not known read: Connection reset by peer
The DNS result was being returned by my router, but SSHFs was clearly not working and -o debug showed why.
Adding the host to /etc/hosts enabled it to work.
It’s not clear why it was needed (which is obviously not ideal).
(Fedora 32)
Method 18
I had this same issue. These options helped me:
sshfs -odebug,sshfs_debug,loglevel=debug
In return I got:
SSHFS version 2.10.0
fuse: bad mount point `allow_other,default_permissions,IdentityFile=/home/rbr/.ssh/id_rsa’: No such file or directory
…which gave me the direction where to look for.
All methods was sourced from stackoverflow.com or stackexchange.com, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0