2

Hellow world!

So I've started developing a project that will run on rPi-3B+. I've run into a problem with SSHFS.

Right now I'd really like to be able to edit, and commit, the git repo stored on the Pi from my text editor, atom, on my laptop over SSHFS.

The first time I mounted the file system it worked fine running this command:

sudo sshfs -o allow_other pi@xxx.xx.xx.xxx: ../../mnt/ceresPi2/

Then I started getting this error in terminal:

read: Connection reset by peer

This thread in this forum from a few years ago was all I found but then I noticed a comment on it from less than a month ago: Connection reset by peer using sshfs

I've done all the steps suggested by everyone in that thread and am still getting the same result.

The second to last comment, by eddygeek, talks about a debug command which gave me the same result as their self:

sshfs -odebug,sshfs_debug,loglevel=debug -o Ciphers=arcfour -o Compression=no -o allow_root -o transform_symlinks localhost:/ /mnt/your_mount_point

gives

command-line line 0: Bad SSH2 cipher spec 'arcfour'.
read: Connection reset by peer

They claim this doesn't happen in fedora but does in ubuntu without an explanation.

I can't seem to find a reason for that online. Would any of you have encountered this recently on Ubuntu or know of a solution?

What's stranger is that I have a second pi running different software but I can mount it to '/mnt/ceresPi1/' without a problem. I can mount it to the same '/mnt/ceresPi2/' pount as well. The Pi giving the issues won't mount to the 'ceresPi1' mount point either, nor to a fresh one @'/mnt/ceresPi3'.

It doesn't even get to the point of asking me for the user password, as I'm not using the saved keys at the moment, since that's just another failure point while I figure this part out.

My stop gap measure is to push a commit to my gitHub repo and then pull it down to the pi server since SSH still works but not SSHFS. obviously this is not ideal.

.

  • 1
    This may be a duplicate of How can I use arcfour encryption over sshfs – RubberStamp Oct 17 '18 at 22:15
  • Possibly a duplicate. It gave me another thing to try. Unlike the OP in that post I got a much different auth.log out put. Problem Pi: Oct 18 15:41:41 hostName sshd[1894]: Connection closed by xxx.xx.xx.xxx port 52618 [preauth] – AustinFoss Oct 18 '18 at 15:51
  • Working Pi: Oct 18 09:41:19 hostName sshd[807]: Accepted password for pi from xxx.xx.xx.xxx port 51794 ssh2 – AustinFoss Oct 18 '18 at 15:55
  • I really am at a loss. Both are rPi3B+'s, both running raspbian stretch and fully upgraded. ssh/sshfs -V out puts the same version for all 3 devices, my laptop and the 2 pi's. One pi, the problem pi, is running stretch lite however...... – AustinFoss Oct 18 '18 at 16:11
1

Okay, I got it working. Thank you Rubber Stamp for providing the link that gave me a trail to follow. I'm not to sure what was causing this issue because normal SSH functionality remained usable.

So I ended up running a debug inline with my normal mount command:

sudo sshfs -o allow_other -d -o debug pi@xxx.xx.xx.xxx: ../../mnt/ceresPi2/

And it suggested running:

sudo ssh-keygen -f "/root/.ssh/known_hosts" -R "172.16.89.189"

Which fixed the issue. I've received that suggestion with normal SSH in the past. Usually after reinstalling raspbian. What's strange is that my known hosts was accepted when just running normal ssh to the same host.

That part I still don't get.

| improve this answer | |
  • The command you issued removes all locally stored keys for the remote host. ssh is a "trust on first use" (TOFU) system. So, if a remote system has changed its host keys or IP address, the "known_hosts" record will not match. Perhaps, an update changed the host keys. – RubberStamp Oct 18 '18 at 17:01
  • Actually I think I just figured it out. My SSH known_hosts are stored in my users local folder. Where as my SSHFS known_hosts are stored in my root directory. This probably happens because when I just use ssh I don't prefix it with sudo, but I do when using SSHFS because I need root permissions to mount to /mnt/. I could probably fix this by creating a sub directory in /mnt/sshfs/ and giving my user read/write access to that one and I'd never have to worry about the /root/.ssh/known_hosts issue. – AustinFoss Oct 18 '18 at 19:17
1

arcfour has been disabled by default in recent versions of SSH.

| improve this answer | |
  • 1
    (1) It looks like that wasn’t the problem in this case. (2) Can you provide steps for a user to take to fix the problem? … … … … … … … … … … … Please do not respond in comments; edit your answer to make it clearer and more complete. – G-Man Says 'Reinstate Monica' Jan 20 '19 at 20:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.