When working on the web you need a way to make changes to your server.
The most common way to do this is via SSH. This is why you will hear people say things like “this is what I saw when I SSH’d in”.
What they mean is they have connected into the server via their terminal and ran some commands.
Today I will try and give you an overview for beginners on SSH and how to use it well.
SSH stands for Secure Shell.
A Shell is a program that provides a text-only interface to Linux and Unix-like operating systems.
If you have used Terminal or iTerm2 on the Mac, a terminal on Linux, or something like Cygwin on Windows you have used a Shell before.
Secure means that is it built on secure protocols. You will be connecting to the remote Shell securely.
When you run a command on your terminal, the window you are typing to is talking to the machine that launched the terminal.
When you have connected via SSH anything you run is actually being ran on the machine you have connected to.
This means that SSH is a way for you to open a terminal session on a remote computer. There is no magic behind it.
Here is an example of how you could connect to a server
This would try and connect to the server that
mysite.com points to with the username ‘shelly’. We are going to cover this in more detail soon.
So why do we need SSH? There have been tools for communicating with remote servers for a long time but most of them transmitted your password in plain text. This meant if someone was listening to the commands you were sending they could get your password and then send commands of their own.
ssh is the command that we type, which feels small enough to sound like it is something built into the operating system you use (much like typing
cd changes a directory) but actually
ssh is a program that needs to be installed on the machine. Luckily for most people it comes pre-installed with your operating system.
The project’s name is OpenSSH, and it is actually a suite of programs, as well as
ssh it also has
ssh-add, and more. If you have spent any length of time developing you will have stumbled across these programs before.
Now seems like a great time to share OpenSSH’s banner which is a joy to behold.
There are a handful of different ways you can authenticate yourself with the server that you are wanting to connect to. I am going to cover the ones we use most often.
Before we start, something to bare in mind is that being authenticated on a server just means it recognises who you are, in order to run certain commands your user might need authorisation, going into that in detail is out of the scope of this article.
This is the easiest form of authentication.
ssh email@example.com example the server would see that someone calling themselves ‘shelly’ was trying to connect with it and it would ask the person for her password.
After comparing the offered password with what was stored for that user the server would either grant access or not.
This works fine but it means you need to remember / manage a password and the password gets stored in plaintext on your computer’s history which isn’t ideal.
Public Key Authentication
This is the preferred method of using SSH.
Public Key Authentication expects your computer to have a securely generated key-pair (A public and private key).
I won’t go into this in detail, but here are the basic steps.
- Your computer will send the public key to the server.
- The server will check if this key is allowed to connect.
- Once connected the server will use the public key to encrypt data that is sent to your computer.
- Your computer will decrypt data with your private key.
Here is how the SSH command might look if you were using Public Key Authentication
Identical! This is because SSH is smart and will try and authenticate with your public key first, it will fall back to asking for a password should it not find one.
If you want more information on setting up your key-pair I’ve found Github’s guide on generating SSH Keys to be useful. You need to keep the private key secret and secure – especially if the key is used to gain access to multiple systems.
You may have heard about needing a
.pem key to connect to something via SSH. This is common and is often used as the standard way to connect to a machine hosted on Amazon EC2.
.pem file is just a text file that can contain your public key, private key, or both. There is nothing special about the file.
In Amazon’s case the
.pem file is the private key for the server and it stores the public key. This way many people can log into the same server so long as they have the correct
Connecting with a
.pem file is different from the first two we have looked at.
-i /path/to/my/pem_file.pem to tell SSH what identity file to use. In other words, don’t worry about trying to identify us with public keys or passwords, use the data in this file.
Some Useful Flags
In our last example we seen the use of the
-i flag, there are a few other ones I have used in the past which I wanted to share here. You may not use these all the time but they are handy to know.
-F /path/to/my/config/fileShortly I am going to explain the use of config files, if you want to specify a custom one for your connection this is what you would use.
-p 666If your server doesn’t use the standard port to listen to SSH connections you can specify a different one.
-nAllows you to background the SSH program in favour of what you want to run on the server. For example you could run
ssh -n mywebsite.com vim &and this will open vim but the session will be on the server.
-vThis is verbose mode, this will print lots of debug messages, this is useful when your connection doesn’t want to work and you don’t know why.
On Mac and Linux machines you can find this information by typing
man ssh into the terminal.
Some Useful Settings
We don’t want to have to remember to type the full command and flags each time we want to connect to our site.
A powerful aspect of SSH is that you can configure it to do all the heavy lifting for you.
We can edit SSH’s config to allow us to give a nice name to our connection which will turn this;
To do this we need to edit (or create) the
You don’t have to put every single thing into the config file but anything set will get used as a default value unless you override it.
ssh foo@mysite would connect with all the details found in the config file but will use the user ‘foo’ instead of ‘shelly’.
Here are some resources I found useful whilst researching this post;