0

I'm behind a corporate network with an HTTP proxy. I also have an SSH server to reach on port 22. I don't have any kind of control over that server: I'm not root and even if I were I'm not allowed to install software or change configuration. The server listens on port 22, must be reached there and this cannot be changed ever.

If I configure XShell (but the same should apply to any other client) to use the corporate proxy I can't connect. Wiresharking it shows that CONNECT method gets refused by proxy because "that's not an SSL standard port".

I believe that the proxy blocks traffic to ports other than 80 and 443. Without doing deep packet inspection or other esotheric tricks.

I have been linked an article about configuring HTTP proxy for SSH "when the proxy filters SSH protocol" but the problem is that it works for Linux and I have another problem with it (it doesn't detect network card, already asked here...).

The question is: how to bypass the proxy without installing software or changing configuration on the target machine?

I would also like to understand

  1. Since the proxy blocks port 22 instead of SSH protocol by deep packet inspection, does the linked guide work when the server listens on port 22 and cannot be changed any way ever?
  2. Is there a way to make it work on Windows?

2 Answers 2

2

For any corporate proxying issue I suggest proxytunnel (over corkscrew) because it makes the traffic completely indistinguishable from real HTTPS traffic, even if full packet-sniffing were to be used.

This solution requires a https server under your control (possibly on the same machine your ssh server is running) which the corporate proxy talks to.

The answer to your first question is: proxytunnel will work around your corporate proxy blocking except in the unlikely case they generally block your https server. Further docs are found here.

I use it with great success on an linux machine. There appear to be docs and binaries for windows around (2nd question):

http://proxytunnel.sourceforge.net/download.php

http://egret.psychol.cam.ac.uk/techniques/firewall.html

If you are lucky in your situation a simpler solution could also do the job. Together with corkscrew just setup an intermediate ssh server somewhere which forwards a port with blessing of your corporate proxy to port 22 of your target ssh server.

5
  • Sorry. I said that the proxy blocks port 22 on the CONNECT invocation, it doesn't give the client the time to initiate SSH handshake. So no DPI, just port filtering and absolutely no way to change the machine's listening port Jan 17, 2013 at 8:35
  • Question needs clarification. I can't install software on the target machine. I'm not root there Jan 17, 2013 at 8:41
  • OK +1 because if I find another server where I can install software I can use it as HTTPS->SSH proxy to the target server. I might accept the answer, many thanks :) Jan 17, 2013 at 8:47
  • The second link is particularly well made and detailed. I'm eager to test it!
    – user39559
    Jun 28, 2013 at 13:16
  • At the "further docs are found here" link, corkscrew is not mentioned. I know this is a few years later, but - can you elaborate on how corkscrew "comes into the mix"?
    – einpoklum
    Nov 3, 2019 at 23:46
-1

A while back I had this problem at a local library. The only difference: I administer the server I wanted to connect to, so I could have changed the setting to ssh in on a different port.

The point was, I did not want to, and I should not have to.

My solution was:

~$ torify ssh [email protected]

That worked for awhile. Now the local library blocks tor ports. The only way around that with this method is to configure the tor circuit established by torify to use a bridge.

These are not ideal solutions, but they are simple, effective, secure if your ssh server is set up right, and they don't require exceptional settings on the server or setting up some specific server for the purpose.

The downside is, your server firewall will see more frequent attacks than before, and your ssh logs will show connections from say Belarus or Ukraine or whatever exit node the traffic is ultimately received from. This can be a little unnerving if you do not trouble to document your remote access and correlate it to the logs.

1
  • 1
    Partially incorrect. The problem with getting more frequent attacks is not due to the use of Tor, but to simply having port 22 exposed. Maybe you understand that, but didn't clearly state it. Also, I disagree on sentence "block Tor ports", because Tor hides itself in port 443 traffic. Obviously it doesn't mean proxies can't catch it (because you have an example there), but it's just to highlight on the form Mar 10, 2016 at 7:52

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .