Key-based logins for SSH
Here’s the scenario: You have a remote-hosted Linux server that you currently access via SSH by entering a username and password. You would like to use a public/private key pair so that you don’t have to enter a password every time you log in. You do most of your work from a Windows/Mac client, where you generally don’t mess with the command line and would rather not bother to learn. Here’s how to enable key authentication for the root user on your remote Linux server. Once you’ve gone through the process you’ll be able to easily replicate it for any other user accounts that require SSH access. 1. Create the key pair from your server
I don’t know what your local system looks like, nor do I care. We know the server has everything you need since it already has SSH installed, so let’s just do the heavy lifting from there! SSH into your server as root, and run the following commands:
ssh-keygen -t rsa
Your output from the call too <a href="http://www.manpagez.com/man/1/ssh-keygen/">ssh-keygen</a> will look something like this:
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
You may enter a passphrase to encrypt the key, but keep in mind you’ll have to enter that passphrase every time you wish to connect, effectively defeating our purposes for using keys in the first place. Just leave the password lines blank when prompted. [Sidebar]
In practice, the connection procedure for passphrase’d SSH keys and standard username/password combo look exactly the same: connect to server > enter password > get access. However, using keys with a passphrase is far more secure than a simple username/password challenge. A would-be attacker needs the key file AND the passphrase in order to get in. This extra layer of connection requirements raises the security bar significantly, especially if you’re careful about where/how you store the file and passphrase.
[/Sidebar] 2. Which keys go where?
If you navigate to /root/.ssh, you’ll find 2 files: id_rsa (the private key) and id_rsa.pub (the public key). Here’s the part that causes the most confusion for newcomers to key-based authentication:
The public key (id_rsa.pub)** belongs on your remote server**.
The private key (id_rsa)** resides on your local client**, or whatever machine is connecting **to** the remote server.
It seems counter-intuitive for some people, especially if you're familiar with SSL. The SSH connection process has the remote server giving offering up the public key for every connection request, placing the onus on the client (i.e. you) to respond with the proper private information. **3. Install the public key on the server**The public key is on the server, but not in the right place yet. We need to place it where SSH will look for it when a key-based connection is made.
cd ~/.ssh
cat id_rsa.pub >> authorized_keys
SSH looks for potential public key matches in the file authorized_keys. The file might be called authorized_keys2 on some systems. The cat command appends the entire key to that file, or creates it if it doesn’t already exist.
At this point the file id_dsa.pub is no longer needed. For the sake of security, you may tuck it away somewhere for safe-keeping, and delete the server copy.
4. Install the private key on your local client
Pull id_rsa (without the “.pub”) down to your local machine using your file transfer method of choice. Once you have a local copy, you should remove the one located on the server, and throw another copy in a dark corner somewhere for safe keeping. This is especially important when setting up key-based authentication for the root user: if you lose the key and disable password logins (discussed below), you will be unable to connect to your server via root. No bueno.
At this point you need to add the key to the SSH connection details of whatever SSH client you use. This fairly straightforward with nearly any SSH client, save one: PuTTY. For whatever reason, the PuTTY team uses a special format for SSH keys, and we need to convert your private key to that format before we can connect.
5. Convert SSH private key for PuTTY on Windows
-
* Open the PuTTY Key Generator. The executable is called `puttygen.exe`
* From the Menu select **Conversions > Import key**
* Browse to your local copy of `id_rsa` and choose Open.
* Click the **Save private key** button, listed under Actions on the lower portion of the window.
* Save the resulting .ppk file in a permanent location (PuTTY will look for the file in this location every time you connect)
* Open PuTTY, and load the saved session for your server
* Navigate to configuration menu to **Connection > SSH > Auth**
* Click the **Browse** button under **Private key file for authentication**, find your new .ppk file, and click **Open**
* Be sure to save the changes made to your PuTTY session!
Using keys-based authentication allows you to enforce better protection on your server from SSH-based attacks. Test your connection before completing going any further.**
Connect to your server using your fancy new SSH key, and open /etc/ssh/sshd_config in your favorite editor. Find the entry for PasswordAuthentication, or add the line as follows:
PasswordAuthentication no
Save and close the file, then restart SSH (on Debian/Ubuntu systems the command will be /etc/init.d/ssh restart). That will prohibit all SSH connections allow you to still connect as root, but only using your key. Again, make sure your key-based authentication is working properly before applying this change.
Update:
Depending on your configuration, you may run into a problem when connecting. If you are receiving an error like Server refused our key, you’ll want to take a look at the end of the auth.log
tail /var/log/auth.log
If you find a line that says Authentication refused: bad ownership or modes for directory in relation to the user your are configuring, then the permissions are screwed up for your .ssh folder. These commands will fix it:
chmod go-w ~/
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
Line 1 removes all write permissions from group and other users for the home directory.
Line 2 Ensures that only the user can access the .ssh folder.
Line 3 restricts actions on authorized_keys to just read and write.
comments powered by Disqus