[SOLVED] Whonix 8 Broke the SSHFS Instructions

Support
1

I consistently rely upon the SSHFS instructions and just upgraded my Whonix install from version 7 to 8. Everything in the instructions worked well under Whonix 7. Under Whonix 8 the instructions don’t seem to be compatible anymore. Also the two following pages have conflicting instructions in them.

http://kkkkkkkkkk63ava6.onion/wiki/File_Transfer#SSH_into_Whonix-Gateway

http://kkkkkkkkkk63ava6.onion/wiki/Sshfs_into_Whonix-Workstation

“Look at the /etc/whonix_firewall.d/30_default config file.”

vs.

“echo “GATEWAY_ALLOW_INCOMING_SSH=1” | sudo tee -a “/etc/whonix_firewall.d/50_user””

In Whonix 8, I modified the 30_default file, which seems to be the right one. Host to Gateway SSH working this way.

“/usr/bin/ssh.real user@192.168.0.11”

vs.

“ssh.real 192.168.0.11”

In Whonix 8, with “/usr/bin/ssh.real user@192.168.0.11” I get the following error:

“bash: /usr/bin/ssh.real: No such file or directory”

In Whonix 8, with “ssh.real 192.168.0.11” I get the following error:

“libtorsocks(12021): connect: Connection is to a local address (192.168.0.11), may be a TCP DNS request to a local DNS server so have to reject to be safe. Please report a bug to Google Code Archive - Long-term storage for Google Code Project Hosting. if this is preventing a program from working properly with torsocks
ssh: connect to host 192.168.0.11 port 22: No such file or directory”

I’m blocked at the “ssh.real” step not working with the libtorsocks error.

I can SSH and SSHFS into the Gateway fine, but the hop to the Workstation is not working yet.

I’ve been using SSHFS successfully on a daily basis with Whonix 7, so could the SSHFS instructions be updated to work with Whonix 8, please?

Thanks!

2

ssh.real changed to ssh.whonix-orig. Updated the articles.

"Look at the /etc/whonix_firewall.d/30_default config file."
Look at means, please read the file. Then the conflict between 30_ and 50_ becomes a non-conflict.
In Whonix 8, I modified the 30_default file, which seems to be the right one.
Both works. Generally, it is better to modify "50_" files. Reason for this and background knowledge is a bit better documented here: https://www.whonix.org/wiki/Whonix_Configuration_Files
"bash: /usr/bin/ssh.real: No such file or directory"
ssh.real changed to ssh.whonix-orig. Updated the articles.
libtorsocks(12021): connect: Connection is to a local address (192.168.0.11), may be a TCP DNS request to a local DNS server so have to reject to be safe. Please report a bug to http://code.google.com/p/torsocks/issues/entry if this is preventing a program from working properly with torsocks
The usual "ssh" command is socksified by default (for stream isolation https://www.whonix.org/wiki/Stream_Isolation). The non-socksified version must be used.

It should be fixed now. But I haven’t tested it.

This is a quite common misconception when using default-socksified applications for local connections. I opened a github issue:
https://github.com/Whonix/Whonix/issues/164

3

Thank you for the assistance…

Okay, after reviewing the updated instructions, with the ssh.whonix-orig command…

ssh -t user@127.0.0.1 -p 2200 “ssh.whonix-orig user@192.168.0.11”

Normal SSHing from Host to Gateway to Workstation is now working.

However, SSHFS is not working.

ssh -f user@127.0.0.1 -p 2200 -L 2222:192.168.0.11:22 -N
sshfs -p 2222 user@127.0.0.1:confused: ~/mountworkstation

I get the following error after the second command:

“channel 2: open failed: administratively prohibited: open failed”
read: Connection reset by peer"

Maybe this is due to the “ssh” command being replaced by the “ssh.whonix-orig” command?

In the SSHFS instructions, there is no input of the “ssh.whonix-orig” command, since the host machine does not use “ssh.whonix-orig”, but the Whonix-Gateway needs it.

4 
Maybe this is due to the "ssh" command being replaced by the "ssh.whonix-orig" command?

Unlikely. It was a simple rename. And when you use ssh.whonix-orig, you’re using the real ssh command.

(You can also entirely uninstall this uwt wrapper, see: Stream Isolation But I don’t think this is required or the root of this issue.)

In the SSHFS instructions, there is no input of the "ssh.whonix-orig" command, since the host machine does not use "ssh.whonix-orig", but the Whonix-Gateway needs it.
There is no need for sshfs.whonix-orig, because there is no sshfs uwt wrapper. On the host you never need this ".whonix-org", because there is not yet a Whonix host operating system, therefore there won't be any uwt wrappers on the host, therefore normal "ssh" / "sshfs" commands can be used on the host.
"channel 2: open failed: administratively prohibited: open failed" read: Connection reset by peer"
I experienced this bug in Whonix 7 already sometimes. It is a bug in ssh or sshfs. It has to do with what fingerprints ssh(fs) is (not) trusting, I think. Search engines are full with it. This issue can be very difficult to fix. I wasted some hours on it already. Hence, this sshfs thing is unfortunately for frustration tollerant / advanced users only. Sorry to say.

On the host. Try this if you are having problems. This might not be neccessary.

For troubleshooting, the article contains these changes.

THINK FIRST!

killall ssh
killall sshfs

On the host. Try this if you are having problems. This might not be neccessary. There seems to be a bug with existing ssh known_hosts files.

THINK FIRST!

or “rm” if you know what you are doing

trash-put ~/.ssh/known_hosts
trash-put ~/.ssh/known_hosts.old

#rm ~/.ssh/known_hosts
#rm ~/.ssh/known_hosts.old

If you don’t have trash-put installed, comment out “rm” and try this. When having these files deleted, you may be lucky and able to fix this issue.

5

Thank you for the follow up, Patrick…

On the host you never need this ".whonix-org", because there is not yet a Whonix host operating system,

Correct. I do realize this distinction. My host operating system is generic Debian Wheezy.

I experienced this bug in Whonix 7 already sometimes. It is a bug in ssh or sshfs. It has to do with what fingerprints ssh(fs) is (not) trusting, I think. Search engines are full with it. This issue can be very difficult to fix. I wasted some hours on it already. Hence, this sshfs thing is unfortunately for frustration tollerant / advanced users only. Sorry to say.

Correct. I too, originally spent many many hours dealing with this in Whonix 7 to get SSH/SSHFS hopping to work for me.

On the host. Try this if you are having problems. This might not be neccessary.

For troubleshooting, the article contains these changes.

THINK FIRST!

killall ssh
killall sshfs

On the host. Try this if you are having problems. This might not be neccessary. There seems to be a bug with existing ssh known_hosts files.

THINK FIRST!

or “rm” if you know what you are doing

trash-put ~/.ssh/known_hosts
trash-put ~/.ssh/known_hosts.old

#rm ~/.ssh/known_hosts
#rm ~/.ssh/known_hosts.old

If you don’t have trash-put installed, comment out “rm” and try this. When having these files deleted, you may be lucky and able to fix this issue.

Correct. I had originally done these steps, as I’ve always done them with my Whonix 7 SSHFS setup as well. No current SSH/SSHFS processes existed (killed them). No current known_hosts files existed (rm’d them).

Here’s my thinking about the SSH/SSHFS commands…

Currently, in Whonix 8, I can successfully SSH hop from Host to Gateway to Workstation. SSH hopping is working fine, if I include the “ssh.whonix-orig” command into the hop statement for the Gateway to Workstation step…

ssh -t user@127.0.0.1 -p 2200 "ssh.whonix-orig user@192.168.0.11"

However, let’s examine the first ssh part of the SSHFS hop command…

ssh -f user@127.0.0.1 -p 2200 -L 2222:192.168.0.11:22 -N

On the Host to Gateway step, this “ssh” command should work fine, as you mentioned.

However, once this hop statement gets to the Gateway to Workstation step, isn’t it just going to repeat another “ssh” command inside the Gateway, instead of the now renamed “ssh.whonix-orig”?

There seems to be nothing here telling the Gateway to use the renamed “ssh.whonix-orig” statement.

In the normal SSH (non-SSHFS) hop command, the “ssh.whonix-orig” statement gets put into the second part of the command…

ssh -t user@127.0.0.1 -p 2200 "ssh.whonix-orig user@192.168.0.11"

So, why wouldn’t the SSHFS hop command also need to be instructed of this renamed “ssh.whonix-orig” command once it gets to the second Gateway to Workstation hopping step?

It just seems like the Gateway to Workstation step can no longer use the “ssh” command, but somehow needs to be instructed to use the renamed “ssh.whonix-orig” command.

6

[quote=“GregGlue, post:5, topic:205”]However, let’s examine the first ssh part of the SSHFS hop command…

ssh -f user@127.0.0.1 -p 2200 -L 2222:192.168.0.11:22 -N

On the Host to Gateway step, this “ssh” command should work fine, as you mentioned.

However, once this hop statement gets to the Gateway to Workstation step, isn’t it just going to repeat another “ssh” command inside the Gateway, instead of the now renamed “ssh.whonix-orig”?

There seems to be nothing here telling the Gateway to use the renamed “ssh.whonix-orig” statement.[/quote]
As far I understand “ssh -f user@127.0.0.1 -p 2200 -L 2222:192.168.0.11:22 -N” uses ssh from the host. It doesn’t need the ssh binary from Whonix-Gateway. The binary required in memory for ssh’ing has already been loaded on the host. Another reason why I think this is not the case is that these instructions worked for Whonix 7 as well. The only changed part was the “.whonix-org part”. The ssh/sshfs commands are unchanged.

But since seeing is beveling and since your idea is not unreasonable, feel free to restore the original ssh command. See:

After applying this, there will be no more Whonix specific additions to that ssh command. And when you run “ssh 192.168.0.10” in Whonix-Gateway for testing, it won’t show that torsocks error anymore. Then you removed all Whonix specific changes and are back to a basic sshfs problem.

7
The only changed part was the ".whonix-org part". The ssh/sshfs commands are unchanged.

Correct. Yet, it’s funny that the normal SSH hop statement does currently require passing in the “ssh.whonix-orig” command name in order to successfully complete a second hop from Gateway to Workstation.

ssh -t user@127.0.0.1 -p 2200 "ssh.whonix-orig user@192.168.0.11"
As far I understand "ssh -f user@127.0.0.1 -p 2200 -L 2222:192.168.0.11:22 -N" uses ssh from the host. It doesn't need the ssh binary from Whonix-Gateway.

Ok, then this would nullify my theory, if that is the case.

Has been a while since I looked at the man page for the inner mechanics of the SSHFS hop statement, so I’m not currently sure.

But since seeing is beveling and since your idea is not unreasonable, feel free to restore the original ssh command. See: https://www.whonix.org/wiki/Stream_Isolation#Deactivating_an_uwt_wrapper

Looks like I might have to go this route next in order to get it working again. Thank you.

It would be nice if someone could at least confirm a successful attempt to SSHFS into Whonix-Workstation with a stock Whonix 8 install, so that we can know that the “ssh” rename to “ssh.whonix-orig” does not break the SSHFS File Transfer instructions.

8

SSHFS into Whonix-Workstation instructions are working for me with Whonix 8. Some notes:

  • i needed to add myself to the fuse group, though (I extended the instructions)
  • i run into a “read: Connection reset by peer”, which I could fix by
    – killall ssh
    – killall sshfs
    – mv ~/.ssh ~/__.ssh

sshfs is urgently waiting for someone to report this bug. Countless work hours worldwide must have been wasted on this already.

9

Thank you.

I’ve got it working now on stock Whonix 8.

Beyond the “ssh.whonix-orig” change, issues were likely to do with my personal configuration.

Reset everything to clean state on host, imported new Whonix 8 VMs, and got it working with updated instructions.

Thanks again, Patrick!