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@132.234.100.123:/home/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@132.234.100.123 echo blah
Using ssh produces the following error and terminates ssh session.
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! 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 5c:0c:ab:ad:7b:32:c8:f3:b0:5d:4d:44:8c:9f:ef:93. 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 132.234.100.123 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@132.234.100.123 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 '132.234.100.123 (132.234.100.123)' 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 '132.234.100.123' (RSA) to the list of known hosts. kamil@132.234.100.123's password:
The sshfs should also work now.
sshfs kamil@132.234.100.123:/home/kamil /mnt/rec
Running the above produces a password prompt and then ends with successful sshfs mount.
kamil@132.234.100.123's password:
Lets have a look what is now mounted.
mount
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@132.234.100.123:/home/kamil on /mnt/rec type fuse
(rw,nosuid,nodev,max_read=65536,user=kamil)
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: http://linux.dsplabs.com.au/forums.
February 25th, 2008 at 4:10 am
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?
jimzat
February 25th, 2008 at 5:21 am
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
March 26th, 2008 at 11:14 pm
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
March 27th, 2008 at 3:20 am
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
kamil@kw32:~$
Hopefully it spits out more debug for you.
April 18th, 2008 at 6:07 pm
Clear and perfect
many thanks
April 21st, 2008 at 11:08 am
Hi!
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!
Woland
April 22nd, 2008 at 1:59 am
good point, ssh server is not installed by default on Ubuntu, thanks Woland
May 4th, 2008 at 1:20 am
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.
June 18th, 2008 at 8:00 pm
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…
June 30th, 2008 at 8:12 am
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.
/home/user/.ssh/privatekey
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.
October 27th, 2008 at 9:14 am
Thank you very much, this was exactly what I needed,
thought I did not have the
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
I did have the 'read: Connection reset by peer' and everything worked fine.
January 2nd, 2009 at 6:11 pm
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
#/bin/bash
echo "${1}"
if [ ! -d /home/${USER}/mnt/${1} ]; then
mkdir -p /home/${USER}/mnt/${1}
fi
sudo sshfs ${USER}@${1}: /home/${USER}/mnt/${1} -C -o allow_other
January 22nd, 2009 at 11:10 am
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!
July 2nd, 2010 at 8:21 pm
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