SSH Access Using Keys

Access to Linux and Unix systems via Secure Shell (SSH) is standard practice.  It offers encrypted access to enable you to administer your server which is vital over the big bad internet.
There are different ways to access SSH: password, user keys and host-based keys.  Passwords are the most common but are less secure than key-based access.  Passwords are susceptible to keylogger attacks, as well as more likely to fool users into a “man-in-the-middle” attack (one where you think you’re logging onto your server, but you are actually proxying your connection through another server which has been compromised and is recording every keystroke and data transfer.

Key based access is more secure as it requires two parts of a key to be present before access is granted.  When dealing with cloud based services such as Rackspace and Amazon Web Services, key based access is enabled by default.  Key based access is also known as “passwordless access” as access is granted by your key, not by asking for any passwords.  The exception to this is if you put a password on your key (but you can enable services that ask for this password once and it is cached for the rest of your session).

Setting this up on your Linux server is very simple, and most installations of SSH (OpenSSH) enable both password and key-based access by default.  Let’s assume user@client needs to access user@server

1. Ensure OpenSSH is installed on your Linux server (server)
   Debian/Ubuntu

    sudo apt-get install openssh-server

   CentOS/Fedora/RedHat/Oracle Enterprise Linux

     sudo yum install openssh-server

2. Ensure the following lines has been uncommented from /etc/ssh/sshd_config

   RSAAuthentication yes
   PubkeyAuthentication yes

3. Restart OpenSSH
   Debian/Ubuntu

    sudo /etc/init.d/ssh restart

   CentOS/Fedora/RedHat/Oracle Enterprise Linux

    sudo /etc/init.d/sshd restart

   On your Linux client (desktop or other server you’ll be using to connect to the server configured in steps 1-3)

4. Generate your public and private keys

   ssh-keygen -t rsa

   You will see output like the following:
   Generating public/private rsa key pair.
   Enter file in which to save the key (/home/user/.ssh/id_rsa):
   Created directory ‘/home/user/.ssh’.
   Enter passphrase (empty for no passphrase):
   Enter same passphrase again:
   Your identification has been saved in /home/user/.ssh/id_rsa.
   Your public key has been saved in /home/user/.ssh/id_rsa.pub.
   The key fingerprint is:
   79:e1:08:77:c2:0d:c4:ff:35:22:64:9a:4d:03:b8:67 user@client
   The key’s randomart image is:
   +–[ RSA 2048]—-+
   |       ++.                      |
   |      …o=                    |
   |      ..+O+.                 |
   |      .oE*+.. o             |
   |       oS oo o .            |
   |         .  .                     |
   |                                  |
   |                                  |
   |                                  |
   +—————–+

5. This produces two important pieces of data.  Your PRIVATE KEY (~/.ssh/id_rsa) and your PUBLIC KEY (~/.ssh/id_rsa.pub).  You must keep your PRIVATE KEY safe.  Your public key can be given to anyone.  Without your private key your public key is just a string of characters and you can’t generate a private key from a public key.  Equally, you can’t generate a public key from a private key.  Together they make your key-pair.
6. To enable your private key to access the server running SSH configured in steps 1-3 (server) you simply copy the contents of your public key onto the server.

   scp .ssh/id_rsa.pub user@server:
   (enter your password)ssh user@server
   (enter your password)
   mkdir --mode=0700 .ssh
   cat .ssh/id_rsa.pub >> .ssh/authorized_keys
   chmod 0600 .ssh/authorized_keys

   This creates the directory .ssh/ and relevant authorized_keys file with the correct permissions (anything less strict will not work).  You can put in a number of public keys in here, line-by-line.  When there are multiple entries it allows multiple people to connect to that account using their keys.  This becomes useful when a team of system administrators require access to systems with minimal accounts installed, but each are accountable for audit purposes as to who logged onto the system.

7. Log out of that session and log back in again and you shouldn’t be asked for a password.

Troubleshooting

If you are being asked for a password it could be a permissions issue or some configuration of OpenSSH that isn’t right.

OpenSSH issues
First, start by tailing the /var/log/secure log on the server (you will need to be root to do this)

Server:

 tail -f /var/log/secure

Client

ssh user@server

You will see log entries being produced as you log in.

Still none-the-wiser?
You can add verbose messages to your ssh session by adding -v to your command line.  Adding more ‘v’ on the command line increases the verbosity.

ssh -vvv user@server

Permissions
Check that permissions of your private key (and .ssh area) on your client are only readable by you, and not group or world readable.
Check the permissions of the .ssh and authorized_keys on the target server are also only readable you.

Kevin Jackson

A confident, highly skilled IT professional with experience of
managing technical teams, specialising in areas of Unix and Linux,
virtualisation, internet technologies and cloud computing. I am
certified in Red Hat Linux and have over 10 years of commercial Unix
and Linux experience. As the Infrastructure Architect for Trader
Media Group I am exposed to a wide range of web hosting technologies
and problems, security threats and tools, and cloud infrastructure
software and methodologies. I'm married with 3 kids and live up the
coast from Liverpool, England.

Specialties
Linux, Unix, Networking, System Design, Web Services, Internet
technologies, Web Application Security, Virtualisation and Cloud
Computing

More Posts - Website - Twitter - LinkedIn