SSH Keys and SSH Hardening in CentOS 7
I touched on SSH configuration in my post about performing the initial configuration on my CentOS Pi. Aside from one tweak to the config file, there wasn't a lot to do. In this post, I'm going to dive a bit deeper into how SSH Keys work, how to set it up in your environment, and then I'll dive a bit deeper into locking down the SSH configuration.
You probably already know that using strong passwords or passphrases are good but they can still be hacked. What if there was a way to secure SSH remote access to a server but not have to worry about passwords? Sure, you could create a policy that forces users to have passwords that are a specific length, contain special characters, etc. But, why worry about passwords at all? With SSH Key Authentication, you create a public/private key pair, put the public key on your server(s) and give a private key to your users (rather, configure their SSH clients to use the private key). The Public key acts kind of like a lock, while the the private key is the key (pun intended). Or, you can think of it as the 2 keys that are needed to launch nuclear missiles in the movies. The keys are encrypted using 2048bit RSA encryption (which I'll talk more about in another post).
The Main idea of what I'm doing is that I'm generating two keys: One public and one private. The public key lives on the server that I'll be connecting to and the private key lives on my workstation(s) that I'll use to connect to my server. I'll create the keys, configure the permissions surrounding the keys, copy the private key to my desktop, and configure my SSH client to use that key when connecting to this server. Let's get started.
On my Pi, I'm going to run a command to generate the RSA public and private keys.
The Keys are placed in the ~/.ssh directory, as shown below. The Private key is the id_rsa file while the Public key is the id_rsa.pub file. As stated earlier, we'll need to copy the private key data to a text file on our workstation. In my SSH client, MremoteNG, I was able to copy the text from a text editor and paste it into Notepad on my Windows workstation and I can confirm that the same action works with PuTTY.
Still logged into our Pi, let's create a blank text document named authorized_keys and copy the public key data into that file. This can be done by using the cat command and piping the output to the authorized_keys file we created.
cat id_rsa.pub >> ~/.ssh/authorized_keys
From there, we'll want to limit the permissions to the .ssh directory and the files containing the public key data. The commands below will limit the permissions so that the owner of the files can read/write (and execute in the case of the chmod 700 command).
$ chmod 700 ~/.ssh
$ chmod 600 ~/.ssh/authorized_keys
Note: If you're connecting to your server from a Linux workstation then it's recommended to apply the same permissions to the .ssh directory and the private key file on your workstation.
At this point, I'm done working on the Pi's SSH key. Let's turn to the private key I have as a txt document into a working private key. In my case, I'm configuring my private key on my Windows workstation.
Using PuTTY, which you can download here, open up the PuTTYgen application that comes bundled with PuTTY. click on the Load button to load a the txt file with the private key data.
Once the data is loaded, you don't have to change anything. Just click the Save private key button, just under the Load button. (I've crossed out my private key info for the screenshot).
If you're using PuTTY as your SSH client, then put in your IP address and enter a name for your saved session (I chose rpi1), and then click on Connection > Data on the tree on the left.
In the Data window, set the Auto-login username to whatever the username is for your account on your server.
Once that's entered, click on Connection > SSH > Auth. In the SSH Auth options, click the Browse button and select the private key we saved with PuTTYgen. It should be in a .ppk format.
Now, click the Open button at the bottom of the window. You should see something like the screenshot below.
In my case, PuTTY isn't my usual SSH client, I'm going to configure MremoteNG to use my new private key. Since MremoteNG uses PuTTY for SSH1, SSH2, and Telnet connections, I can leverage the PuTTY session we just created in MremoteNG.
In MremoteNG, click on Tools > Config and create a new connection In the Protocol field, select your saved PuTTY Session.
Now, in View > Connections, right-click on the saved connection and select Connect.
Now that we've gotten our SSH client configured, we can lock down SSH for better security. We've already blocked the root account from connecting via SSH to this sever, but now we're going to only allow our new user account (the one that we created during our initial configuration), disable SSHv1 connections (which are less secure than SSHv2 connections), and disable password authentication (since we're logging in using SSH keys).
For the most part, these options are already present in the configuration file. We just need to uncomment them, save the file and run the command below to restart the SSH daemon.
sudo systemctl restart sshd.service
The only exception to the rule above is that I had to add a line to my SSH config in order to limit user accounts that can open an SSH connection the line looked like
AllowUsers Ahale
That's it! If you were following along, you've now got SSH key authentication working on your server. I hope this helped you better understand SSH as well as how public/private keys work.
SSH Key Authentication
You probably already know that using strong passwords or passphrases are good but they can still be hacked. What if there was a way to secure SSH remote access to a server but not have to worry about passwords? Sure, you could create a policy that forces users to have passwords that are a specific length, contain special characters, etc. But, why worry about passwords at all? With SSH Key Authentication, you create a public/private key pair, put the public key on your server(s) and give a private key to your users (rather, configure their SSH clients to use the private key). The Public key acts kind of like a lock, while the the private key is the key (pun intended). Or, you can think of it as the 2 keys that are needed to launch nuclear missiles in the movies. The keys are encrypted using 2048bit RSA encryption (which I'll talk more about in another post).
SSH Key Configuration
The Main idea of what I'm doing is that I'm generating two keys: One public and one private. The public key lives on the server that I'll be connecting to and the private key lives on my workstation(s) that I'll use to connect to my server. I'll create the keys, configure the permissions surrounding the keys, copy the private key to my desktop, and configure my SSH client to use that key when connecting to this server. Let's get started.
On my Pi, I'm going to run a command to generate the RSA public and private keys.
The Keys are placed in the ~/.ssh directory, as shown below. The Private key is the id_rsa file while the Public key is the id_rsa.pub file. As stated earlier, we'll need to copy the private key data to a text file on our workstation. In my SSH client, MremoteNG, I was able to copy the text from a text editor and paste it into Notepad on my Windows workstation and I can confirm that the same action works with PuTTY.
Still logged into our Pi, let's create a blank text document named authorized_keys and copy the public key data into that file. This can be done by using the cat command and piping the output to the authorized_keys file we created.
cat id_rsa.pub >> ~/.ssh/authorized_keys
From there, we'll want to limit the permissions to the .ssh directory and the files containing the public key data. The commands below will limit the permissions so that the owner of the files can read/write (and execute in the case of the chmod 700 command).
$ chmod 700 ~/.ssh
$ chmod 600 ~/.ssh/authorized_keys
Note: If you're connecting to your server from a Linux workstation then it's recommended to apply the same permissions to the .ssh directory and the private key file on your workstation.
At this point, I'm done working on the Pi's SSH key. Let's turn to the private key I have as a txt document into a working private key. In my case, I'm configuring my private key on my Windows workstation.
Using PuTTY, which you can download here, open up the PuTTYgen application that comes bundled with PuTTY. click on the Load button to load a the txt file with the private key data.
Once the data is loaded, you don't have to change anything. Just click the Save private key button, just under the Load button. (I've crossed out my private key info for the screenshot).
If you're using PuTTY as your SSH client, then put in your IP address and enter a name for your saved session (I chose rpi1), and then click on Connection > Data on the tree on the left.
In the Data window, set the Auto-login username to whatever the username is for your account on your server.
Once that's entered, click on Connection > SSH > Auth. In the SSH Auth options, click the Browse button and select the private key we saved with PuTTYgen. It should be in a .ppk format.
Now, click the Open button at the bottom of the window. You should see something like the screenshot below.
In my case, PuTTY isn't my usual SSH client, I'm going to configure MremoteNG to use my new private key. Since MremoteNG uses PuTTY for SSH1, SSH2, and Telnet connections, I can leverage the PuTTY session we just created in MremoteNG.
In MremoteNG, click on Tools > Config and create a new connection In the Protocol field, select your saved PuTTY Session.
Now, in View > Connections, right-click on the saved connection and select Connect.
SSH Configuration Best Practices
Now that we've gotten our SSH client configured, we can lock down SSH for better security. We've already blocked the root account from connecting via SSH to this sever, but now we're going to only allow our new user account (the one that we created during our initial configuration), disable SSHv1 connections (which are less secure than SSHv2 connections), and disable password authentication (since we're logging in using SSH keys).
For the most part, these options are already present in the configuration file. We just need to uncomment them, save the file and run the command below to restart the SSH daemon.
sudo systemctl restart sshd.service
The only exception to the rule above is that I had to add a line to my SSH config in order to limit user accounts that can open an SSH connection the line looked like
AllowUsers Ahale
That's it! If you were following along, you've now got SSH key authentication working on your server. I hope this helped you better understand SSH as well as how public/private keys work.
Comments
Post a Comment