Unfortunately our government filters the SSH protocol so now we can't connect to our Linux server.

They do the filtering by checking the header of each packet in the network layer (and not by just closing port). They also do away with VPN protocols.

Is there any alternative way to securely connect to a Linux server?

  • 7
    This could very well be a first use-case for the Hackerspace Global Grid...
    – S19N
    Commented Jan 2, 2012 at 21:27
  • 35
    If you're considering voting to close this question on the grounds of "too localised", do consider that lots of companies also block ssh at the perimeter, so answers will be of interest to many more people than those who have to communicate across this border. Whilst questions about subverting local firewall settings might be thought unwise they are not, as far as I know, closeable for that reason only.
    – MadHatter
    Commented Jan 3, 2012 at 8:54
  • 3
    I think we want to avoid the politics, but do need to discuss the technical issues even when we recognize that they may be used to violate someone's policy. The point is that technically valid security policies can be in conflict. See meta.security.stackexchange.com/questions/664/…
    – nealmcb
    Commented Jan 4, 2012 at 16:56
  • mosh.mit.edu might also be worth a shot Commented Oct 23, 2013 at 11:41
  • My school blocks SSH, but I port forward to use port 53 or similar. Commented Apr 5, 2015 at 19:34

11 Answers 11


From what I heard earlier today, https/ssl flows correctly through your borders.

You should hence check out Corkscrew.

Similarly to netcat, it's used to wrap ssh in https to allow the use of https proxies.

Another solution would be to use LSH which, by having a different signature than ssh, works from Iran as Siavash noted it in his message.

  • 1
    Actually, you should be able to just change the ssh port to 443 and then connect through it. Unless they are doing a man-in-the-middle attack they shouldn't be able to tell the difference between ssh and https. This has worked on all firewalls I've tried it on. I added an answer for this, please let me know if it works.
    – user606723
    Commented Jan 4, 2012 at 17:01
  • 13
    @user606723: The ISP (and the govt) is the man in the middle. This is not an attack, but surveillance. And yes, they are able to tell the difference between ssh & https by using DPI.
    – petrus
    Commented Jan 4, 2012 at 18:08
  • 3
    Maybe the handshake is different between ssl and ssh?
    – user606723
    Commented Jan 4, 2012 at 18:12
  • 6
    A SSL/TLS handshake is unencrypted. You can easily see protocol version, supported cyphersuites(from the client), chosen cypher, virtual host(provided the extension is used, and most browsers do), the certificates presented. You can use this information to try to fingerprint the server/client software. In short TLS does not try to hide itself, it only tries to protect the application data after the handshake completed. I don't know much about the SSH encryption layer, but its handshake surely looks different from TLS. You don't need an active MitM, passively looking at the packets is enough Commented Jan 6, 2012 at 17:34
  • 2
    An SSH connection begins with the server sending "SSH" in clear text, so it's trivial to spot for anyone watching the connection. Does corkscrew actually obscure this, or does it just set up the connection through proxies and leave the "SSH" visible?
    – Kevin
    Commented Jan 10, 2012 at 16:36

Based on a talk at the CCC conference - 28C3: How governments have tried to block Tor - the Tor Project has the best track record in this dynamic and challenging field, and it can be used for SSH. Innovative usage of Tor bridges is one of the latest developments. The 28C3 Tor talk is also on YouTube and the slides are at https://svn.torproject.org/svn/projects/presentations/slides-28c3.pdf

Note that using evasive methods that can be identified too easily can expose the user to yet more violations of their human rights and personal security. Be careful.

Update: Article 19 of the The Universal Declaration of Human Rights is relevant here:

  • Article 19: Everyone has the right to freedom of opinion and expression; this right includes freedom to hold opinions without interference and to seek, receive and impart information and ideas through any media and regardless of frontiers.
  • "Note that using evasive methods that can be identified too easily can expose the user to yet more violations of their human rights" - Not that I agree with the type of filtering that Iran and others do, but I hardly think that the use of SSH should be considered a human right.
    – MDMarra
    Commented Jan 3, 2012 at 19:05
  • 10
    @MDMarra I don't believe Neal is trying to say SSH itself is a human right. It's what SSH tunneling enables (free speech, and access to information) for those in such restricted countries, which is.
    – Iszi
    Commented Jan 3, 2012 at 19:20
  • 3
    I think the problem here is that the OP wants to do something perfectly harmless, even from a restrictive government's perspective, but the means to do it securely are either outlawed or 'suspicious', so using them may lead to all sorts of problems with the authorities.
    – tdammers
    Commented Jan 4, 2012 at 7:07
  • 2
    @MDMarra - In a world where net access is becoming increasingly important, the Right to Internet Access is being increasingly debated.
    – Mark Booth
    Commented Jan 4, 2012 at 15:02
  • Vint Cerf, father of the Internet and Matrix Architect look-alike seems to disagree
    – MDMarra
    Commented Jan 5, 2012 at 20:23

If you have unfiltered https you can do something like AjaxTerm or any other AJAX or HTML5 based terminal emulator running on a protected site within a webserver that can either connect to a local ssh daemon or in certain cases to remote ones on other interfaces of your machine.

Another option (tough a bit obscure) if you have ICMP to your box would be to run TCP/IP on top of ICMP if that is open. See here.

  • no tunnel with AjaxTerm I guess?
    – petrus
    Commented Jan 3, 2012 at 14:26

Try sending the SSH handshake over more than 1 packet. A lot of packet filtering technology operates on a packet level and won't buffer for the inspection.

If this doesn't work, try doing this but sending the two or more parts of the handshake out of order. Only if the DPI box is reassembling would it catch the handshake.

  • 8
    how do I do this in practice? lower the MTU? Commented Nov 18, 2012 at 11:48
  • 3
    @JanusTroelsen: Modify your ssh client and server to send S, S, H in separate write calls with sleep 1 in between them.
    – Joshua
    Commented Sep 11, 2017 at 15:15
  • Is there any tutorial available for that? @Joshua
    – Tayyebi
    Commented Oct 26, 2022 at 8:49

You have several options for tunneling IP over other protocols. Besides using something like corkscrew, you could try implementing IP/DNS (i.e. with iodine) or IP/ICMP.

In other case you could also use something like http://www.serfish.com/console/


You can also consider tunneling SSH traffic over DNS using tools like OzymanDNS or iodine


You could use something like VNC, but without a secure tunnel like a VPN or SSH, it's not very secure. If they filter that too, you're going to have a hard time.

  • 8
    I tested it too,it has been filtered too:| enjoy your freedom mans because you were not born in the hell:|
    – Moein7tl
    Commented Jan 2, 2012 at 21:27

Another option, but one that will require that you first get access to your server some other way so you can install the daemon, is telnet-ssl/telnetd-ssl.

Unlike some of the other options that have been suggested, this won't require a lot of network overhead, and is very simple to use (once the daemon is running).

  • It is unlikely that port 992 is fully open if port 22 is closed.
    – ceving
    Commented Jan 5, 2012 at 10:04
  • but 443 may be open. And I am pretty sure it's impossible to tell the difference between https and telnet-ssl.
    – user606723
    Commented Jan 5, 2012 at 16:24
  • In principle it shouldn't be possible to recognize what kind application is running on top of SSL/TLS. But the handshake offers plenty of fingerprinting possibilities. So unless special care is taken, it's probably often possible to at least tell which client SSL library is used. Presence of the virtual hostname extension and the list of supported cypher suites would be the first things I'd look at when trying to differentiate https and telnet-ssl. Active probing, as China does, is another possibility, and relatively hard to protect against. Commented Jan 6, 2012 at 17:42

If you know that your current internet connection is being filtered, then use a different internet connection method like a satellite internet service provider. There are a number of different satellite internet service providers: list1, list2.

(The author's original question did not state any restrictions on getting some alternate form of connectivity.)

  • 7
    This sounds like a great to get detained as a "Western spy".
    – ceejayoz
    Commented Jan 3, 2012 at 14:58

You should be able to just change the ssh port to 443 and then connect through it. Unless they are doing a man-in-the-middle attack they shouldn't be able to tell the difference between ssh and https.

This has worked on all firewalls I've tried it on. (admittedly not that many)

I would be interested to hear if this works. Thanks.

  • Using port 443 for SSH works on most firewalls. +1 for this. But it requires an additional tool for the SSH connect command. See here for details: daniel.haxx.se/docs/sshproxy.html
    – ceving
    Commented Jan 5, 2012 at 10:07
  • @ceving, Why do we ned that? I haven't.
    – user606723
    Commented Jan 5, 2012 at 15:29
  • Passive DPI is probably enough to detect the difference between SSL and SSH. SSL/TLS has a easily visible handshake. Commented Jan 6, 2012 at 17:55
  • @CodeInChaos: maybe it is visible, but nobody look at.
    – ceving
    Commented Jan 9, 2012 at 22:07
  • 1
    The OP said that it's not just filtered based on port. And there are certainly countries who tried to filter TOR based on DPI, so it's not unlikely that Iran filters SSH with DPI. Commented Jan 9, 2012 at 22:18

I have the same problem. Nowadays initial SSH connection is established but after some packet transmission it's dropped. I believe they have started to drop SSH packets after a limit is reached. I have switched to MOSH https://mosh.mit.edu/. It authenticates using SSH and then switches to UDP. It's faster than SSH and easy to install and use.

To use it, just install it on your server, open udp port 60000:61000 in firewall and connect to the server with a mosh client like you do with a ssh client (There is no need to start anything).

sudo yum install mosh
sudo iptables -I INPUT 1 -p udp --dport 60000:61000 -j ACCEPT

A good windows client is MobaXTerm http://mobaxterm.mobatek.net/download-home-edition.html

You must log in to answer this question.

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