A recent update to my Raspbian Raspberry Pi has made arcfour sshfs fail.
From the client:
$ sshfs pi:~ /tmp/alskdjflkasdf/ -o Ciphers=arcfour
read: Connection reset by peer
On the server at /var/log/auth.log:
Oct 23 22:13:58 raspberrypi sshd[5909]: fatal: no matching cipher found: client arcfour server aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected],[email protected] [preauth]
How can I reenable arcfour?
Seems like the server does not want to allow it based onthe output of auth.log. I'd try adding arcfour back into the SSH server's sshd_config file. From the sshd_config man page:
Ciphers
Specifies the ciphers allowed for protocol version 2. Multiple
ciphers must be comma-separated. The supported ciphers are
“3des-cbc”, “aes128-cbc”, “aes192-cbc”, “aes256-cbc”, “aes128-ctr”,
“aes192-ctr”, “aes256-ctr”, “[email protected]”,
“[email protected]”, “arcfour128”, “arcfour256”,
“arcfour”, “blowfish-cbc”, and “cast128-cbc”. The default is:
aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,
[email protected],[email protected],
aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,
aes256-cbc,arcfour
Incidentally, there is nothing wrong with your -o Ciphers=arcfour switches from what I can tell. I even found this SU Q&A titled: sshfs mount without compression or encryption that shows the same approach.
/etc/ssh/sshd_config hadn't changed for me for ages, so I suppose some package upgrade modified the default behaviour. My manually including arcfour, it now works again.