sshfs giving "remote host has disconnected"

Question

I am trying to mount an sftp connection into a folder using sshfs with the following command which throws an error.

~$ sshfs admin@example.com:/ testfo
remote host has disconnected

The same error happens if I SSH into the system and repeat the command by with localhost. This command also worked with another machine so therefore the issue is somewhere on the server.

~$ cat /var/log/auth.log

[...]

May 24 22:49:43 example sshd[20095]: Accepted publickey for admin from 24.111.222.33 port 47086 ssh2: RSA ad:xx:6e:xx:14:xx:bd:b5:xx:cb:66:xx:xx:xx:a3:ac
May 24 22:49:43 example sshd[20095]: pam_unix(sshd:session): session opened for user admin by (uid=0)
May 24 22:49:43 example systemd-logind[812]: Removed session 60.
May 24 22:49:43 example systemd-logind[812]: New session 61 of user admin.
May 24 22:49:44 example sshd[20143]: Received disconnect from 24.203.164.45: 11: disconnected by admin
May 24 22:49:44 example sshd[20095]: pam_unix(sshd:session): session closed for user admin

The ~/.ssh directory is owned by admin since I saw that as a debugging attempt for a similar issue.

Additional information for future reference:

The issue is not with SSH itself, but with SFTP. This is manifested by the fact that SSH connections work correctly but SFTP always fails. Attempting to SFTP results in Received unexpected end-of-file from SFTP server

The issue is not related to login scripts outputted strings (e.g. ~/.bashrc).

The issue is present from all users (including root).

Here is my sshd configuration (/etc/ssh/sshd_config):

# Package generated configuration file
# See the sshd_config(5) manpage for details

# What ports, IPs and protocols we listen for
Port 22
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes

# Lifetime and size of ephemeral version 1 server key
KeyRegenerationInterval 3600
ServerKeyBits 1024

# Logging
SyslogFacility AUTH
LogLevel INFO

# Authentication:
LoginGraceTime 120
PermitRootLogin yes
StrictModes yes

RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile %h/.ssh/authorized_keys

# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# For this to work you will also need host keys in /etc/ssh_known_hosts
RhostsRSAAuthentication no
# similar for protocol version 2
HostbasedAuthentication no
# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication
#IgnoreUserKnownHosts yes

# To enable empty passwords, change to yes (NOT RECOMMENDED)
PermitEmptyPasswords no

# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no

# Change to no to disable tunnelled clear text passwords
#PasswordAuthentication yes

# Kerberos options
#KerberosAuthentication no
#KerberosGetAFSToken no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
#UseLogin no

#MaxStartups 10:30:60
#Banner /etc/issue.net

# Allow client to pass locale environment variables
AcceptEnv LANG LC_*

Subsystem sftp sftp-server

# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM yes

sftp-server package is installed. (sudo apt-get install openssh-sftp-server)

Answer 1

Old question, but the first one that comes up for this problem.

My issue was the server required key authentication, but I was running the command using sudo and specifying -o IdentityFile=~/.ssh/id_rsa, meaning ~ was expanded to root's home, not mine.

Specifying the full path worked, and I imagine using $HOME would have too (because it would have expanded earlier).

Answer 2

Your Subsystem value in sshd_config is wrong.

It should be Subsystem sftp /usr/lib/openssh/sftp-server or internal-sftp. Try to modify the /etc/ssh/sshd_config to this value, restart the ssh service ans try once more.

Answer 3

You'll get this error if the remote server is running Dropbear rather than OpenSSH.

SSHFS uses SFTP, and Dropbear doesn't provide SFTP. So when you try to use it, the Dropbear server sees a request for a subsystem that it doesn't understand and drops the connection.

From here: https://unix.stackexchange.com/questions/363540/mount-a-filesystem-using-sshfs-using-the-dropbear-server-on-yocto-firmware

Answer 4

I am not sure if it helps, but I had similar problem

remote host has disconnected

and after some googling&browsing I realised, that actually I connected ssh via different port.

So, for example, I had to connect via ssh (example, assuming port number 1234):

ssh username@example.com -p 1234

instead of standard ssh when port number is 22. So the same had to be used for sshfs connection:

sshfs username@example.com:/ ~/testfolder -p 1234

It solved my problem.

Answer 5

One more cause that happened to me was that the dropbearmulti binary itself lacked the string /usr/libexec/sftp-server which got lost somewhere around build 33600 of DD-WRT. Check if said binary mentions this file or it won't work even if it's present. I had to use a binary from build 33525 and make a launcher that kills the normal buggy dropbear, then runs this one. You create a symlink called dropbear pointing to dropbearmulti. You stop the current one with stopservice sshd, then run the working one. See in ps what the proper parameters look like. It's best to have it on jffs (or unpack it to /tmp) so that you could still umount any drive.

Answer 6

If you are able to connect the host via ssh by itself:

ssh xxx.xxx.xxx.xxx

You may be prompted to save the key, you ned to type YES, not just a Y. You should then be asked for the username and password for the user on that remote machine.

Use the one you are trying to do sshfs with, post back your results.

If you get a connection refused, I am guessing that you have not installed SSH on the remote computer. Open ssh can be installed with this command, run on the remote computer:

sudo apt install openssh-server