SSH tunnel from Whonix Workstation to VPS unreliable

Hello!

I’ve setup a Whonix VM for the purpose of remote administering a VPS. My goal is for there to be no way to easily trace the connection between this VPS instance and me.

I need to be able to access this VPS instance through SSH to setup and manage the server.

I’ve successfully managed to connect to the server using the following command:

torsocks ssh user@ip

However, this connection is highly unstable. Sometimes I’m logged off right after logging in. Other times, I’m able to run a few commands before I’m logged off. Usually the connection is not active long enough for me to do anything useful.

When I try to login again after being logged off, my normal authentication method (public key) is usually denied and i’m asked to input the password. (Password and keyboard interactive are in fact disabled for this server but my understanding is SSH always defaults to password in this situation.) I usually have to try a few more times before my public key is accepted again.

Another thing i notice is that every time i connect to this VPS server, SSH warns me that the server fingerprint has changed. (I’ve had to disable strict hostkey checking in the ssh config on the client.) I am in full control of the VPS. I have other similar VPS instances with the same host which function as normal. I have no idea why the hostkey is apparently changing every time I try to login from within Whonix. Furthermore, i can’t login without using Tor because I don’t want to reveal my identity so i can’t test whether this particular VPS works OK over the clearnet or not.

I’ve also tried logging into another similar VPS on the same host using Tor SOCKS5 proxy over Putty. In this case the connection is stable and works perfectly. There are also no warnings about the hostkey changing.

Given that I can access a similar VPS over Tor using Putty without any issues (similar to how it should work on Whonix) this leads me to believe there might be something going on in Whonix that might be causing this issue. Yet despite reading every thread and discussion i could find on this topic, I can’t seem to figure it out.

Could someone please point me in the right direction?

Thank you.

HT

1 Like

!!!

Sounds to me like an attacker is (attempting) to intercept your SSH connection with an MiTM attack using the exit-node. Since you control the server I assume the hostkey in question has not changed.

I hate to be the bearer of bad news but at this point I would assume everything sent to the remote server while the connection was intercepted to be compromised. And if that included the root password - that is in the hands of an attacker.

1 Like

Thank you for the reply.

I’ve researched why this was happening and have already come across the possibility that this might be some sort of attack. I’m far from an expert on these matters but I don’t think this is the right explanation. Here are some reasons:

  1. This happens every time in every Whonix session - which means it happens across multiple endpoints.

  2. There is nothing of value on this VPS.

  3. I’ve destroyed and recreated this VPS a bunch of times in an attempt to solve this issue.

Could there be any other reason why the hostkey appears to be changing?

Just to respond to this again.

I’ve done some further testing, namely by logging into a different VPS on the same host in the exact same way I’m describing above for the problematic VPS instance.

It works perfectly. Everything as expected. This leads me to believe that perhaps there is something else going on. If this is a MITM attack, what do I do? I’ve already destroyed and re-created the VPS multiple times. It appears this hasn’t helped. Do I need to change my IP?

At a guess and without further information - it could be an opportunistic MiTM to avoid detection, potentially targeted against certain networks (for example).

Assuming everything is ok with the VPS the only difference a hypothetical attacker would see would be potentially a different host-key after redeployment. So changing IP at this point would be best.

Afterwards exposing SSH over an onion-service might be a prudent further step. Because that mitigates MiTM attacks by virtue of the public-key being the identifier of the onion-service.

A quick update in case anyone else stumbles upon this: This was a problem with the host. I think the IP I was using was assigned to more than 1 machine. I switched to another VPS and didn’t have any issues anymore.

1 Like