153

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?

Community
  • 1
Moein Hosseini
  • 1,293
  • 2
  • 9
  • 7
  • 7
    This could very well be a first use-case for the Hackerspace Global Grid... –  Jan 02 '12 at 21:27
  • 34
    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. –  Jan 03 '12 at 08: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 http://meta.security.stackexchange.com/questions/664/conflicting-policies-and-discussing-technical-issues-involving-privacy-vs-contr – nealmcb Jan 04 '12 at 16:56
  • http://mosh.mit.edu/ might also be worth a shot – Tobias Kienzler Oct 23 '13 at 11:41
  • My school blocks SSH, but I port forward to use port 53 or similar. – Elliot Gorokhovsky Apr 05 '15 at 19:34

11 Answers11

90

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.

blue112
  • 113
  • 5
petrus
  • 804
  • 6
  • 5
  • 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 Jan 04 '12 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 Jan 04 '12 at 18:08
  • explain how this can be done only using DPI and not any sort of intervention? Or perhaps I should create a question? For reference, "man-in-the-middle attack" refers to something specific. http://en.wikipedia.org/wiki/Man-in-the-middle_attack – user606723 Jan 04 '12 at 18:11
  • 3
    Maybe the handshake is different between ssl and ssh? – user606723 Jan 04 '12 at 18:12
  • @user606723: ssh is a protocol. ssl is an encryption mecanism, used with FTP and http for example. This has nothing in common. – petrus Jan 04 '12 at 18:17
  • I suppose you're right. for the record, ssl is a protocol as well. – user606723 Jan 04 '12 at 18:20
  • 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 – CodesInChaos Jan 06 '12 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 Jan 10 '12 at 16:36
  • @Kevin If you check the source it sends a HTTP Proxy request and a base64 encoded request, so I don't think it does anything to actually hide the plain text identifier of the protocol, just a change in the technology used to access it. – scragar Jul 21 '14 at 08:54
24

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.
nealmcb
  • 20,544
  • 6
  • 69
  • 116
  • `"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 Jan 03 '12 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 Jan 03 '12 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 Jan 04 '12 at 07:07
  • 2
    @MDMarra - In a world where net access is becoming increasingly important, the [Right to Internet Access](http://en.wikipedia.org/wiki/Human_rights#Information_and_communication_technologies) is being increasingly debated. – Mark Booth Jan 04 '12 at 15:02
  • Vint Cerf, father of the Internet and Matrix Architect look-alike [seems to disagree](http://news.dice.com/2012/01/05/cerf-internet-access) – MDMarra Jan 05 '12 at 20:23
  • @MDMarra Thanks for the link. I think Cerf is right. For the situation here, I'll note Article 19 of the [The Universal Declaration of Human Rights](http://un.org/en/documents/udhr) which is more what I was trying to get at, and with which I expect Cerf would agree: "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." – nealmcb Jan 06 '12 at 17:36
  • @nealmcb Fair enough, my larger point (which is too large for a comment, actually) is that I don't think that it should be up to us to decide what is and isn't right for a foreign sovereign nation to police within their borders. While I vehemently disagree with the filtering in Iran and other similarly suppressed nations, I don't think it's my place to provide workarounds for governmental policy. Sure, it's probably black&white to most for this specific issue, but it's a slippery slope. If you open the door for one round of governmental subversion, where does the line get drawn for other cases – MDMarra Jan 06 '12 at 18:04
  • @MDMarra Indeed - it isn't easy. Many problems are over-constrained, as diverse and reasonable goals and policies conflict. For further discussion see http://meta.security.stackexchange.com/q/664/453 – nealmcb Jan 07 '12 at 01:50
13

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.

pfo
  • 231
  • 1
  • 3
11

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.

strtok
  • 111
  • 3
10

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/

ashwoods
  • 201
  • 1
  • 4
7

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

5

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.

MDMarra
  • 325
  • 3
  • 13
  • 8
    I tested it too,it has been filtered too:| enjoy your freedom mans because you were not born in the hell:| –  Jan 02 '12 at 21:27
5

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).

TimB
  • 151
  • 2
  • It is unlikely that port 992 is fully open if port 22 is closed. – ceving Jan 05 '12 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 Jan 05 '12 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. – CodesInChaos Jan 06 '12 at 17:42
5

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.)

4

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.

user606723
  • 822
  • 5
  • 10
  • 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: http://daniel.haxx.se/docs/sshproxy.html – ceving Jan 05 '12 at 10:07
  • @ceving, Why do we ned that? I haven't. – user606723 Jan 05 '12 at 15:29
  • Passive DPI is probably enough to detect the difference between SSL and SSH. SSL/TLS has a easily visible handshake. – CodesInChaos Jan 06 '12 at 17:55
  • @CodeInChaos: maybe it is visible, but nobody look at. – ceving Jan 09 '12 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. – CodesInChaos Jan 09 '12 at 22:18
2

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

Ali
  • 121
  • 3