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

http://www.mmncs.com/2011/07/setup-openssh-sftp-server-on-synology-nas-and-connect-using-sshfs-from-your-linux-ubuntu-web-server/

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

#/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

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

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

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…

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.

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

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.

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

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

jimzat