Far from trivial unless you’re willing to brick ssh completely, or at least cripple a bunch of non-VPN uses for tunneling. Of course it’s trivial to just block ssh outright, or block tunneling above a certain bandwidth. But that would also block, as an example, most remote IDE sessions, loopback-only server management frontends, etc.
The Kremlin could maybe have something set up that looks for accesses to stuff inside Russia from outside Russia, then flag that IP as suspicious as being a VPN endpoint outside Russia.
So, okay, take this scenario:
IP A, user inside Russia.
IP B, VPS outside Russia.
IP C, service inside Russia that state can monitor.
User in Russia on IP A has an SSH tunnel to VPS on IP B with SOCKS that they control.
That’s fine as long as user is only browsing the Internet outside Russia. But if you’re routing all traffic through the VPS and you use any sites in Russia, the Great Russian Firewall can see the following:
IP A has a long-running SSH connection to IP B.
IP B is accessing stuff in Russia.
You could maybe also do heavier-weight traffic analsysis on top of that if you see 1 and 2, or gather data over a longer period of time, but seeing 1 and 2 alone are probably enough to block IP A to IP B connections.
That can be defeated by using two external VPSes, opening an SSH tunnel to the first one, and then talking to SOCKS on the second (maybe with another SSH connection linking the two). But that’s increasing complexity and cost.
can be defeated with two VPSes, but that’s increasing complexity and cost
A marginal increase, perhaps. You don’t need a separate VPS - just a second IP. Accept incoming traffic on port 22 on one, and set the default route for outbound traffic to the other.
Far from trivial unless you’re willing to brick ssh completely, or at least cripple a bunch of non-VPN uses for tunneling. Of course it’s trivial to just block ssh outright, or block tunneling above a certain bandwidth. But that would also block, as an example, most remote IDE sessions, loopback-only server management frontends, etc.
The Kremlin could maybe have something set up that looks for accesses to stuff inside Russia from outside Russia, then flag that IP as suspicious as being a VPN endpoint outside Russia.
So, okay, take this scenario:
IP A, user inside Russia.
IP B, VPS outside Russia.
IP C, service inside Russia that state can monitor.
User in Russia on IP A has an SSH tunnel to VPS on IP B with SOCKS that they control.
That’s fine as long as user is only browsing the Internet outside Russia. But if you’re routing all traffic through the VPS and you use any sites in Russia, the Great Russian Firewall can see the following:
IP A has a long-running SSH connection to IP B.
IP B is accessing stuff in Russia.
You could maybe also do heavier-weight traffic analsysis on top of that if you see 1 and 2, or gather data over a longer period of time, but seeing 1 and 2 alone are probably enough to block IP A to IP B connections.
That can be defeated by using two external VPSes, opening an SSH tunnel to the first one, and then talking to SOCKS on the second (maybe with another SSH connection linking the two). But that’s increasing complexity and cost.
A marginal increase, perhaps. You don’t need a separate VPS - just a second IP. Accept incoming traffic on port 22 on one, and set the default route for outbound traffic to the other.