connection reset by peer — ssh sshfs error 

Recently, after re-installation of Ubuntu Linux, sshfs mount, from a Fedora Core 6, has failed with the following error message, read: Connection reset by peer. In fact this error is not due to sshfs but its ssh subsystem. Unlike ssh, sshfs does not give a very descriptive error in this case. The above error happens due to a possible security threat, namely the man-in-the-middle attack. If we know that the security has not been compromised then it is very likely that the RSA host key has been changed. The fix for the above error is very simple. All one has to do is to remove the cached host key from the ~/.ssh/known_hosts file. This post lists steps needed to get rid of the read: Connection reset by peer sshfs error.

Lets reproduce the error by running the following command from bash.

sshfs kamil@ /mnt/rec

The error message is produced.

read: Connection reset by peer

As mentioned in the introduction the actual error comes as part of inbuilt ssh security measure. To get a more descriptive error message ssh into the host in question instead of trying to sshfs mount one of its paths locally.

ssh kamil@ echo blah

Using ssh produces the following error and terminates ssh session.

Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
Please contact your system administrator.
Add correct host key in /home/kamil/.ssh/known_hosts to get rid of this message.
Offending key in /home/kamil/.ssh/known_hosts:97
RSA host key for has changed and you have requested strict checking.
Host key verification failed.

The highlighted portion of the above warning tells us that the RSA host key on line 97 of the /home/kamil/.ssh/known_hosts file is the offender (it does not match the new credentials on the destination host). Ok, so lets get rid of line 97 of the /home/kamil/.ssh/known_hosts file.

sed -i -e '97d' /home/kamil/.ssh/known_hosts

Done. Lets try the ssh again.

ssh kamil@ echo foo bar

It now works just fine. Note that you will be asked to add the updated credentials to the /home/kamil/.ssh/known_hosts file.

The authenticity of host ' (' can't be established.
RSA key fingerprint is 5c:0c:ab:ad:7b:32:c8:f3:b0:5d:4d:44:8c:9f:ef:93.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '' (RSA) to the list of known hosts.
kamil@'s password:

The sshfs should also work now.

sshfs kamil@ /mnt/rec

Running the above produces a password prompt and then ends with successful sshfs mount.

kamil@'s password:

Lets have a look what is now mounted.


The highligted portion shows the sshfs mount worked.

proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
/dev/hda2 on /boot type ext2 (rw)
sshfs#kamil@ on /mnt/rec type fuse

Hope this helps!

ReferencesRe: [sshfs] Error "Connection Reset By Peer" on pam_mount+sshfs

Did you find the above information useful and interesting? If so, please support this site by using the blog directory links at the bottom of this page. Thanks for your support!

If you have any Linux related problems or questions then please feel free to post them on our Linux Forums:

VPS Hosting Referral Code DZZCC3

Add me to Technorati Favorites Vote for me on Blog Catalog

19 Responses to “connection reset by peer — ssh sshfs error”

  1. jimzat Says:

    I am getting the "read: Connection reset by peer" message also when I attempt to sshfs from one of my Gutsy boxes into a Dapper box. (The connection from my other Gutsy box to Dapper is OK.) But when I ssh from the Gutsy boxes into Dapper everything is fine with no warnings.

    This doesn't appear to be an RSA key issue, what else could it be and how should I diagnose it?


  2. Kamil Says:

    Hmm, it is rather tough to fix things without being able to reproduce the problem in the first place.

    Are you using RSA keys throughout (and not some DSA some RSA)?

    You can configure ssh to 'not care' about miss-matches between credentials and known_hosts entries, if that were the case then you could ssh even when there was a miss-match. On the other hand (maybe?) sshfs uses a different ssh config (seems unlikely tho).

    I am still leaning towards it being an old key issue… that is easy to check, just remove known_hosts file (but make backup first).

    Another suggestion I'll make is to try the ssh 'setup' from GutsyWorking on GutsyNotWorking:
    mv .ssh .ssh.orig
    scp -r jimzat@GutsyWorking:./.ssh .
    Then try sshfs again. If that works then look at the differences between the directories using any of the following:
    diff .ssh .ssh.orig
    kompare .ssh .ssh.orig
    meld .ssh .ssh.orig

  3. Ubuntu For Free Says:

    I'm having no problems with ssh into the box, but I do get the reset by peer error. My keys should all be the same. Is there some kind of a log file I can check to get more specific information

  4. Kamil Says:

    The verbose mode of ssh (ssh -v) gives lots of useful debug info.

    From the sshfs man page:
    -o sshfs_debug
    print some debugging information

    On a successful mount it does not print much info:
    kamil@kw32:~$ sshfs -o sshfs_debug kamil@rec:/ /mnt/rec
    kamil@rec's password:
    Server version: 3

    Hopefully it spits out more debug for you.

  5. spirit Says:

    Clear and perfect
    many thanks

  6. Woland Says:


    I was just having the same problem,and I was scratching my head as your howto didn't help either. Then suddenly I remembered forgetting to install openssh-server on the server side. :))) Hehe, really simple solution!
    BTW, thanks for the howto!

  7. Kamil Says:

    good point, ssh server is not installed by default on Ubuntu, thanks Woland

  8. Azulus Says:

    I was having the connection reset by peer issue and as I was tailing auth.log on the ssh-server I saw the following:

    May 3 18:22:27 ub3r sshd[19954]: subsystem request for sftp
    May 3 18:22:27 ub3r sshd[19954]: subsystem request for sftp failed, subsystem not found

    After that happened on the server I'd receive the connection reset error locally. In the server's /etc/ssh/sshd_config, near the bottom there was an sftp subsystem line commented out. I uncommented it and restarted my SSH server and everything seems to work fine now.

  9. misko Says:

    I had same problem "Connection reset by peer" but it was nothing mention before…

    Problem was stupid…

    My hosting use notdefault port for ssh so in
    sshfs ${ssh_username}@${ssh_server}: ${mount_point}
    I had to change to
    sshfs -p 23345 ${ssh_username}@${ssh_server}: ${mount_point}

    I hope this will help someone…

  10. matt Says:

    For anyone having trouble using keys with names, like me using multiple keys for multiple machines, here's a tip. Say this is your key, and your machine only accepts keys, no passwords.


    If you try to login using the normal "-i" ssh option, you'll get the infamous "Connection reset by peer," and with debug it will show "Permission denied (publickey)."

    (WRONG) sshfs -p 2222 -i /home/user/.ssh/privatekey user@HOST:/docs /home/docs

    Instead you will need to use the "-o IdentityFile=" option (see man ssh_config):

    (CORRECT) sshfs -p 2222 -o IdentityFile=/home/user/.ssh/privatekey user@HOST:/docs /home/docs

    So while the "-o" option works, the "-i" option doesn't. Strange. Perhaps this will change in future versions.

  11. tjh Says:

    Thank you very much, this was exactly what I needed,
    thought I did not have the


    I did have the 'read: Connection reset by peer' and everything worked fine.

  12. bingo Says:

    OK. My problem was because I was using sudo to mount and so _root_ had the old key. So I had to edit the /root/.ssh/known_hosts file to remove the line. That took awhile to figure out :)

    echo "${1}"
    if [ ! -d /home/${USER}/mnt/${1} ]; then
    mkdir -p /home/${USER}/mnt/${1}
    sudo sshfs ${USER}@${1}: /home/${USER}/mnt/${1} -C -o allow_other

  13. Chris Says:

    One of the best written and structured helps that I have read. I particularly like the use of 'sed'. My only gotcha was that I needed to clean out the root's known_host file since I was using 'sudo'. I've only been using 'sudo' for a few months so I didn't think about the implications. Bingo, many thanks for posting your resolution so that I only lost 10 minutes!

  14. Kevin Says:

    I'm a bit late to the game, but thanks from me as well for posting the issue with an out-of-date known_hosts file on root! Once I saw that, I knew that was it. Too bad I already scp'ed everything, but well…now I know and will never forget :)

  15. Durand Says:

    Ahhh, thank you so much!

  16. Tommy Says:

    If you have this problem when you try to sshfs to a Synology NAS you may find a solution description here:

    The Synology NAS does not have openssh-sftp-server installed by default. openssh-sftp-server is required to make a sshfs mount.

  17. Doug H Says:

    Thanks to bingo!

    I had old *root* ssh key in /root/.ssh/known_hosts and had reinstalled server OS. Deleted the server's line in that file and was fine.

    It was confusing as:
    1) I got the "Connection refused" message when doing sudo sshfs….
    2) ssh from prompt (no sudo) was fine

  18. Truong Chuong Duong Says:

    I meet same problem with Doug H, but I found the solution.

    The issue is my server does not include SFTP subsystem when SSHD start. To fix it, do these step:
    1. Try to locate sftp-server (/usr/libexec/sftp-server, or /usr/lib/openssh/sftp-server, or /usr/libexec/openssh/sftp-server in different flavors of Linux). I assume it is /usr/libexec/sftp-server.
    2. edit the file sshd_config (/etc/ssh/sshd_config)
    3. Add this line at end of file:
    Subsystem sftp /usr/libexec/sftp-server
    4. Reload you sshd server by this command: /etc/rc.d/sshd reload

  19. marcustux Says:

    This error also appears, if one enters a wrong domain, that cannot be resolved…

    I entered an invalid domain and it results in the exact same error

    read: Connection reset by peer

Leave a Reply