WTF is SSHing into a server?


You know that moment when you realize, “Uh oh, I’m in WAY over my head?”

I have a lot of those.

A few years ago, I was asked by a colleague to SSH into a server and grep for a file. At the time, this sounded like total nonsense to me – however, since this person clearly thought I SHOULD know how to do whatever this meant, I just said “You bet!” and just started googling furiously. Here’s what I needed to know in that moment.

The concept

First, SSH means ‘Secure Shell’, and it’s also sometimes referred to as ‘Shell Access’. It’s a way for you to access a server securely, without a password, and is done by generating a private key and a public key. The public key gets added to the server, and you keep the private key locally. When you access the server, the private key and public key connect and you are granted access (if you need more info than this, learn about the SSL/TLS handshake here).

Why not just use a password? There’s some debate about this. The crux of it is really that your private key (which is really just a text file on your local machine with a gigantic multi-character string in it) is harder to steal and harder to guess, which means it’s less likely to be successfully cracked in a brute-force attack. You can also password protect your private key, so there’s an extra layer of protection.

The execution

So when you’re SSHing into a server, what you’re doing is really:

  1. Generating a public/private key pair
  2. Putting the public one on the server
  3. Logging in to the server (which you’ll be authenticated onto thanks to your local private key) through the command line
  4. Crossing your fingers and hoping you’re not blowing anything up while you’re in there

Let’s start with generating the key pair. Fire up your terminal/command prompt/iTerm, whatever you use to access the command line. Type:

ssh-keygen -t rsa

It’s then going to ask you for a name for your new key, which will then be saved as a text file on your local machine.

Generating public/private rsa key pair.
Enter file in which to save the key (/Users/you/.ssh/id_rsa): [whatever-you-want-to-call-it]

Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in [whatever-you-want-to-call-it].
Your public key has been saved in [whatever-you-want-to-call-it].pub.

Congrats! You have created a key pair.

Next, we have to copy the key, so we can add it to our server. We do this by again going to the command line and entering:

MAC: pbcopy < ~/.ssh/
WINDOWS: clip < ~/.ssh/

Now that it’s copied, how you proceed is going to depend entirely on where the key needs to go. Here are a couple of links that may help you, depending on your end game:

Adding a new SSH key to your GitHub account

How to enable SSH/Shell Access in cPanel

Connecting to Your AWS Linux Instance Using SSH

BitBucket: Add an SSH key to an account

Digital Ocean: How To Set Up SSH Keys

In my case (and possibly in yours), my colleagues were wise enough to not let me go rooting around on my own, like a freegan in a dumpster, trying to solve the problem; I simply gave them my key and they added it on my behalf, something commonly done on web teams.
In any event, now that the key is on the server, and you have your private key – with or without its own password, depending on your preferences – it’s go time. Here is the anti-climactic final command that will log you in:


In a perfect world, that works no problem, and you feel like a super hacker who is now inside the matrix.
If not, your first troubleshooting exercise should always be to check the server. If you transferred the key yourself, make sure you copied it correctly. Re-copy and re-paste, and try again. If someone else has granted you access, get them to do the same. I’ll add a few more techniques in a future post.
Extra credit reading: