How to SSH into a server protected by Cloudflare DNS

The short answer

Cloudflare’s global DNS can significantly improve your DNS lookup and time to first byte, but it comes with the downside of filtering out all but HTTP(S) requests.

To get around this, you’ll have to access your server either at a custom subdomain not managed by Cloudflare (e.g. ssh.example.com) or at your server’s raw IP address (like 12.345.67.890).

The long answer

We’re always looking at ways to speed up the sites that we build—whether we’re caching page requests, optimising assets by minifying and compressing, or lazy loading assets once a full paint has been performed. We’re speed freaks (the good kind).

But there are certain parts of the page loading process that are going to take time no matter what. For instance, physical distance from the server can introduce a not insignificant amount of latency into any page load. Even though your data is moving at the speed of light, it takes a little time to send a bunch of data through the wires and down to your computer.

We also tend to be freaks about security, so we make sure to secure all of our sites with Let’s Encrypt certificates. But what do you know but a TLS handshake can actually be pretty expensive, time-wise.

And of course, no time-to-first-byte discussion can be complete without complaining about awful DNS lookup times. The prototypical explanation is that DNS is the phonebook of the Internet—it tells your computer where crtr.co.uk, or google.com, or whatever.coolbiz.net can actually be found. Check out Cloudflare’s great intro to DNS if you’re looking for the full scoop.

But so going to look up a site in the Big Internet Phonebook In the Sky (BIPIS) takes a hot second, since it’s actually more like the Big Library of Internet Phonebooks In the Sky. You’re not just going to one phonebook: you’re going to look up a phonebook of phonebooks, and that phonebook will direct you to another phonebook, which will direct you to yet a third, master phonebook, which will send you on to another phonebook, but this one is in Singapore for some reason, and that phonebook will send you back to another phonebook in good ol’ Blighty, and so on and so forth.

Computers are pretty good at this, and pretty fast, too, so you won’t be sitting around long. But while all those DNS phonebook computers are talking to each other, you’ll just be sitting around looking at this:

Cloudflare

Fortunately, Cloudflare hauls out their wall of lava lamps generating cryptographic entropy on the regular to help us out. Specifically, they manage a set of nameservers (essentially, the computers that do the phonebook-lookup for you) that can handle your DNS lookup way faster than your generic out-of-the-box nameservers.

Remember when that one phonebook sent you all the way to Singapore and back? Well, maybe the company you bought your domain from owns a bunch of nameservers in Singapore because it’s cheaper; or maybe they’re based in New Zealand for tax reasons. But for whatever reason, every time someone wants to visit your site, they’ve got to pass through some nameserver on the other end of the globe before they even get the first byte out of your beautiful website banquet.

Cloudflare, however, runs a network of nameservers all over the globe, and makes sure that they all keep in sync with one another. There’s no special data in Singapore or New Zealand that you won’t find on all of the other Cloudflare nameservers. That means that when someone in Sheffield wants to visit your site, it doesn’t matter where you got your domain from, or where your original nameservers are located—you’ll be using Cloudflare’s nameservers in Britain.

Which, obviously, translates to speed.

Trouble time

Cloudflare does a pretty complicated little ballet with your data as well, to keep attackers away and keep your site running. (Probably involves the lava lamps.) But it also means that if you’re used to connecting to your VPS using your domain, you’re going to wind up hanging.

This is because Cloudflare enables an HTTP proxy by default. Whenever someone requests your site, Cloudflare intercepts that request, measures whether or not the request is legitimate (i.e. whether or not it’s part of, say, a DDoS attack), and passes it on if the lava lamps say it’s okay.

That’s great: it means fewer headaches and more uptime for you, the end user. The downside is that Cloudflare only lets HTTP traffic through. Since bots are constantly crawling the web trying to break into servers via SSH and FTP, Cloudflare just shuts it all down. Unfortunately Cloudflare’s blanket ban is going to deny you, the legitimate SSH user, as well.

So what’s a savvy Internet user to do?

Solution time

The quick answer is: just SSH using your publically-accessible IP address. There’s no proxying around a straight IP request. So instead of user@fantasticsandwiches.biz, try accessing user@12.345.67.890 instead. This obviates the need for any DNS lookup at all, since you’re the one telling your browser where to find the server you’re looking for.

Of course, remembering a bunch of IP addresses can be a little tough. And you shouldn’t be expected to have to log into DigitalOcean or Vultr or Linode or wherever you’re managing your VPSes just to fetch the IP address to log into your server. For that reason, Cloudflare also recommends setting up a subdomain to manage non-HTTP connections to your server, and disabling HTTP proxying on that subdomain alone. This means clicking the orange cloud next to the appropriate DNS record to turn it grey.

So for example, say you’ve got your Fantastic Sandwiches site up at fantasticsandwiches.biz and Cloudflare is managing its DNS, but you’ve suddenly developed a burning desire to log into your server. Open goes the console and you type in:

$ ssh myself@fantasticsandwiches.biz

…and nothing happens. Cloudflare won’t send along your DNS queries since you’re not making an HTTP request.

Lucky you, though, since you read this blog and you set up some A records for ssh.fantasticsandwiches.biz pointing to your server and you haven’t let Cloudflare get its powerful and admittedly very efficient HTTP-proxying hands on it. So back you go to your console and lo:

$ ssh myself@ssh.fantasticsandwiches.biz

Welcome to Ubuntu 16.04.4 LTS (GNU/Linux 4.4.0-116-generic x86_64) ...

You’re in! And you don’t have to remember a host of different IP addresses to log into the various servers you’ve got running for clients all over the world. You’re a competent server admin, and all is right with the world.