In this day and age you can never be too careful, this is why ensuring that any interaction you have with your remote servers is done using public and private keys via ssh. I have seen countless times people administering their servers using the root login with a weak password instead of public/private keys.
Your private key file should be kept safe. Under no circumstance should you ever give it out. The private key is the equivalent of the lock and the public key is the equivalent of a key to open that lock. Your generated keys should also be protected by a strong passphrase.
Generating SSH Keys
First things first, lets generate a public/private key pair locally on our machine. Open up a terminal or command prompt window.
We will be checking for the existence of an already generated private/public keypair and using that if they exist, if not we’ll be generating a new pair of keys.
A rule of thumb is to have the one public/private keypair for everything. It is not advisable to generate multiple key pairs as it will offer you no added security benefits. However, I do advocate separate keys for things like Github and hosting environments. You can also pick up discounted servers at points in the year when festivities occur – like the HostGator Cyber Monday Deal 2016, which lets you pick up a few servers for the price of one, to diversify your datacenter loads.
Check for existing keys
Type the following into your terminal/command prompt window.
ls -al ~/.ssh
If you see two files:
id_rsa.pub then it means you already have some generated keypairs and you don’t need to generate any keys.
If you didn’t see the above aforementioned files, you need to generate them by typing the following into your terminal/command prompt window.
ssh-keygen -t rsa -C "email@example.com"
Pay attention to each step, especially the passphrase. I know some people don’t enter a passphrase, but for the sake of that extra level of security, enter a passphrase.
Now running the above
ls command under the heading “Check for existing keys” you should see two files. A private key with no file extension and public key file with an extension of
Preparing your remote server for SSH keys
Now that we have our local keys all sorted (generated or already existent), lets prepare our remote server for our newly generated keys.
Connect to your remote server via SSH and the credentials you’ve been using to login with (most likely root) and then check for the existence of the
.ssh directory in your home directory.
Then we want to check for the existence of the folder:
ls -al ~/.ssh
If the folder does not exist, we will need to create it. Creating the
.ssh directory should require no root permissions as we are in the home directory. If for whatever reason you need too, prefix the command with
Now that we’ve got our
.ssh folder created, lets create an authorized_keys file which will contain our public keys.
Now we have our file which will house our authorized keys, lets ensure the permissions on the folder and file itself are correct.
chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys
Copying our local public key to the server
Now that we have our keys ready to go, our remote server prepared for our public key, we need to copy it to the server. This isn’t as straightforward as it sounds, but you have plenty of options.
If you’re on a Unix style terminal (if you’re a Mac or Linux user) you can simply type the following into your terminal/command line window (replacing the login details for ssh with your own):
cat ~/.ssh/id_rsa.pub | ssh username@yourhost 'cat >> .ssh/authorized_keys'
You can also use
scp to securely copy your public key over, but using the
cat command is definitely the fastest and easiest option.
Now that we have our basic SSH keys setup, we can connect using
ssh username@yourhost but if you connect using an IP address, sometimes it can be a PITA. This is where SSH alias commands come in handy.
All aliases for connecting to remote servers should be done on your local machine. Before proceeding, please ensure you are logged out of your remote server.
Creating an alias configuration file
Alias commands will be stored in the
.ssh directory inside of a file called
config which has no file extension.
Now that we have our file for storing alias commands, we can add them in. The configuration file accepts different configuration options from specifying the port to supplying a unique private key.
In the above example if we wanted to connect to staging we can now just type:
ssh staging or if we wanted to connect to alpha, we would type:
ssh alpha and for connecting with Github, we have specified our own private key file just for Github.
You have no successfully setup your remote server and local machine to connect using public/private keys and best of all: no passwords. We also have created some nice SSH aliases which save us having to write potentially long lines to connect to our remote server.