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

  • 1) Are you able to sftp there directly? What is the content of ~/.bashrc or other startup files in your home directory of the server?
    – Jakuje
    May 25, 2016 at 7:14
  • @Jakuje Hmm.. the issue seems to be in fact with sftp. Trying with filezilla gives Received unexpected end-of-file from SFTP server May 25, 2016 at 12:47
  • 2) Can you sftp to different users? 3) How does you sshd_config on server look like? 4) How does your ~/.bashrc look like?
    – Jakuje
    May 25, 2016 at 12:52
  • @Jakuje Same 2) Nope.. Same error for all users. 3) pastebin.com/raw/ujNk3fVR 4) bashrc got nothing of relevance but here: pastebin.com/raw/mUD3DWmG May 25, 2016 at 16:33
  • What you get from which sftp-server. Subsystem should be Subsystem sftp /usr/lib/openssh/sftp-server. Do you have sftp-server installed? apt-get install openssh-sftp-server.
    – Jakuje
    May 25, 2016 at 17:05

6 Answers 6


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

  • 2
    Thanks, was able to mount with this tip.
    – Bemmu
    Oct 25, 2019 at 13:36

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.


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


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.

  • thank you very much. it works :) Sep 25, 2020 at 9:52

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.


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
  • 1
    Yes I am able to ssh to it. "The same error happens if I SSH into the system[..]" Implied it. Server is setup correctly as far as I know May 25, 2016 at 4:27
  • OK, I may be miss reading your comment, were you successfuly able to login with ssh, or as I read here: "The same error happens if I SSH into the system[..]" May 25, 2016 at 4:34
  • I can ssh to it just fine May 25, 2016 at 4:45
  • OK, looking at your command line maybe you have an extra space? I found this one on line I will send you the link. sshfs <username>@<ipaddress>:/remotepath ~/remoteserv I found it here: howtogeek.com/howto/ubuntu/… There are a bunch of other instructions but in your original question your command seems to have an extra space May 25, 2016 at 4:56
  • I also do not see where you are connecting to your local system as a directory. Your code my code to follow: sshfs admin@example.com:/ testfo May 25, 2016 at 4:58

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .