When trying to setup mounting a directory I wanted to work out of on a remote DigitalOcean Cloud Server, I ran into an issue when issuing the following command:
sudo sshfs -o allow_other,default_permissions,IdentityFile=~/.ssh/id_rsa_digitalOcean firstname.lastname@example.org:/srv/www /mnt/digOceanApacheSrv01
It would just respond with:
read: Connection reset by peer
A clue emerged when I ran the command to mount a directory on a server on my LAN to a mount point on the workstation I was using. The following command just uses password authentication because it’s just a testing server that I didn’t bother to setup ssh keys on. This command did execute and mounted the server’s directory to the folder I specified in the command line.
This worked on LAN using password authentication:
sudo sshfs -o allow_other,default_permissions brandon@a1-apacheSrv:/srv /mnt/a1-webSrv
So, it’s was starting to look like I had an issue with my ssh keys. So after a couple minutes of searching posts online from users that have had various connection issues when trying to mount a remote directory, I stumbled across a post that indicated the IdentityFile wasn’t working out the users home directory by using the tilde (~) in the path name and was recommended to type out the whole path name.
So this: IdentityFile=/home/brandon/.ssh/id_rsa_digitalOcean
Instead of this: IdentityFile=~/.ssh/id_rsa_digitalOcean
The link to the post I’m referring to is: https://superuser.com/questions/1074990/read-connection-reset-by-peer-using-sshfs-to-connect-to-aws
The full modified command I ran was (Note, I also used the actual IP address of the server so I could eliminate DNS being an issue):
sudo sshfs -o allow_other,default_permissions,IdentityFile=/home/brandon/.ssh/id_rsa_digitalOcean email@example.com:/srv/www /mnt/digOceanApacheSrv01
And wouldn’t you know it, it actually worked and mounted my DigitalOcean Droplet directory to my local workstation. Hurray, but I also saw something else in the post that was curious.
The forum user actually included the –o flag for each option instead of separating the various options with commas. Hmmm, I wonder what would happen if I wrote the command out when I specifically list each option with the –o flag but also go back to the original way I wrote that path out.
I knew the IdentityFile option in sshfs was capable of resolving the user’s home directory path using ‘~’ because that’s how I wrote the path out when I successfully connected to the test server on my local area network.
I then proceeded to run the following command on my laptop that was giving me the same error as my work station:
sudo sshfs -o allow_other -o default_permissions -o IdentityFile=~/.ssh/id_rsa_digitalOcean firstname.lastname@example.org:/srv/www /mnt/DigOcean-Apache-NYC3-01
Oddly enough, when separating options, this method also worked. I’m not sure why this method works but I suspect there may be some sort of bug when resolving the ssh key file path when not listing the options individually.
So if you’re pulling your hair out trying to figure out why the connection to your remote server is dropping out with a connection reset by peer error. You may want to see if these 2 methods of writing out the IdentityFile option path might work to get your remote folder mounted to your local workstation.
Good Luck & Peace Out,
Brandon Reilly (9/1/2018)