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.
Important note
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 and id_rsa.pub then it means you already have some generated keypairs and you don’t need to generate any keys.
Generating Keypairs
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 "youremail@domain.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 .pub
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 sudo.
mkdir ~/.ssh
Now that we’ve got our .ssh folder created, lets create an authorized_keys file which will contain our public keys.
cd ~/.ssh
touch authorized_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.
SSH Aliases
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.
cd ~/.ssh
touch config
Alias Examples
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.
Host staging
HostName staging.somewebsite.com
User staging-user
Host alpha
HostName alpha.somewebsite.com
User alpha-user
Port 500
Host github.com
User githubuser
IdentityFile ~/.ssh/github
Host amazon
HostName ec2.amazon.com
User yourec2user
Port 1111
IdentityFile ~/.ssh/amazon
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.
Conclusion
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.
