Connection reset by peer using sshfs

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,[email protected] [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,[email protected] [preauth]
sshd[2456]: debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,[email protected],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96 [preauth]
sshd[2456]: debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,[email protected],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96 [preauth]
sshd[2456]: debug2: kex_parse_kexinit: none,[email protected] [preauth]
sshd[2456]: debug2: kex_parse_kexinit: none,[email protected] [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: [email protected],[email protected],[email protected],ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,[email protected],[email protected],[email protected],[email protected],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,[email protected] [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,[email protected] [preauth]
sshd[2456]: debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,[email protected],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96 [preauth]
sshd[2456]: debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,[email protected],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96 [preauth]
sshd[2456]: debug2: kex_parse_kexinit: none,[email protected],zlib [preauth]
sshd[2456]: debug2: kex_parse_kexinit: none,[email protected],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

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

Answer 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

Answer 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!

Answer 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

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

Answer 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

Answer 7

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

Answer 8

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.

Answer 9

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.

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

Answer 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

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

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

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

Answer 15

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.

Answer 16

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.

Answer 17

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 user@ip:/ /mnt/folder

................
debug1: client_input_global_request: rtype [email protected] 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 user@ip:/ /mnt/folder

So simple and so functional.

Answer 18

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)

Answer 19

I was also receiving the read: Connection reset by peer error. The file permissions on my ssh key were incorrect. Once adjusted as described in this answer, the sshfs mount started working. My issue was specifically the private key file permissions were 644 instead of the required 600 due to copying my ~/.ssh folder over from a backup after a fresh install. The linked answer is pasted below:

• .ssh directory: 700 (drwx------)
• public key (.pub file): 644 (-rw-r--r--)
• private key (id_rsa): 600 (-rw-------)
• lastly your home directory should not be writeable by the group or others (at most 755 (drwxr-xr-x)).

Answer 20

I use sudo ssh username@ip and then exit from remote server, and then sudo sshfs ..., this issue gone! I'm accessing Ubuntu 20.04.6 from Ubuntu 20.04.6