SSH keys for dummies: how to set up ssh_pk authentication

2012-12-20 21:18:00

How to set up SSH keys in three easy steps

Creating and configuring SSH key authentication can be a complicated matter. Ask any techie, including myself, about the process and you are likely to get a very longwinded and technical explanation. I will in fact provide that exhaustive story below, but here's the short version, where you set up SSH key authentication in three easy steps.

 

Quickly setting up SSH key authentication

Generate a new key pair using... ssh-keygen -t rsa ...and just press Return on all questions.
	Install the "lock" on your door using... ssh-copy-id ~/.ssh/id_rsa.pub $host ...where $host is your target system. Or, if ssh-copy-id is not available, copy these instructions.
You're done! Start enjoying your SSH connection! ssh $host

 

Please feel free to print the poster of this three-step approach, just to make sure you don't forget them.

---

 

What is SSH anyway?

SSH, short for Secure SHell, is an encrypted communications protocol used between two computers. Both the login process as well as the actual data interchange are fully encrypted, ensuring that prying eyes don't get to see anything you are working on. It also becomes a lot harder to steal a user account, because simply grabbing the password as it passes over the network becomes nigh impossible.

The name, secure shell, hides the true potential of the SSH protocol as it allows for many more functions. Among others, SSH offers a secure alternative to old-fashioned (and unencrypted) protocols such as Telnet and FTP. It offers:

• Interactiv access to the command line of a remote system.
• Non-interactive command execution on a remote system.
• File transfer in no less than two ways (SFTP and SCP).
• The tunneling of other protocols, thus creating a VPN of sorts.
• Acting as a SOCSK proxy server, again tunneling other traffic.

SSH is cross-platform, insofar that both server and client software is available for many different operating systems. Traditionally it is used to connect from any OS to a Unix/Linux server, but SSH servers now also exist for Microsoft Windows and other platforms.

SSH is capable of using many different authentication and authorization methods, depending on both the version of SSH that is being used and on the various provisions made by the host OS (such as PAM on a Unix system). One is not tied to using usernames and passwords, with certificates, smartcards, "SSH keys" (what this whole page is about) and other options also being available.

Unfortunately, its flexibility and its many (configuration) options can make using SSH seem like a very daunting task.

 

What are SSH keys?

The default authentication method for SSH is the familiar pair of username and password. Upon initiating an SSH session you are asked to provide your username first, then your password, after which SSH will verify the combination against what the operating systems knows. If it's a match, you're allowed to login. If not, you're given another chance or so and ultimately disconnected from the system. However, the need to enter two values manually is a burden when trying to automate various processes. It often leads to hackneyed solutions where usernames and passwords are stored in plaintext configuration files, which really defeats the purpose of using such a secure protocol.

SSH keys provide an alternative method of authenticating yourself upon login. Taken literally, an SSH keypair are two ASCII files containing a long string of seemingly random characters and numbers. These keys are nearly impossible to fake and they only work in pairs; one does not work without the other. The reason why SSH key authentication works, is because what is encrypted using one key can only be decrypted using the other key. And vice versa. This is the principle behind what is known as public key cryptography.

Public key encryption, and thus SSH key authentication, is a horribly complex technical matter. I find that for most beginners it's best to use an analogy.

A keypair consists of two keys: the public and the private key. The public key could be said to be a lock that you install on an account/server, while the private key is the key to fit that lock. The key will fit no other lock in the world, and no other key will fit this particular lock.

Because of this, the private key must be closely guarded, protected at all cost. Only the true owner of the private key should have access to it. This private key file can be protected using a password of its own (to be entered whenever someone would like to use the key file), but it is often not. Unfortunately this means that, should someone get their hands on the private key file, the target account/host becomes forfeit. Thus it's better to use a password protected keyfile in combination with SSH-agent. But that's maybe a bit too advanced for now :)

The public key on the other hand can be freely copied and strewn about. It is only used to set up your access to an account/server, but not to actually provide it. The public key is used to authenticate your private key upon login: if the key fits the lock, you're in. "Losing" a public SSH key poses no security risk at all.

Of course there's one caveat: while losing a public key is not a problem, one should not simply add public keys onto any account! Doing so would enable access to this account/server for the accompanying private key. So you should only install public keys that have good reason for accessing a specific account.

 

How does SSH key authentication work?

So how does SSH key authentication work? It all relies on a public key infrastructure feature called "signing". The exact process of SSH key authentication is described in IETF RFC 4252, but the gist of it is as follows. 

1. The destination system "signs" a test message with your public key
2. The source system verifies that signature using your private key
3. If the signature checks out, then we know that the pair of keys match. You're allowed to login.

As I said, this only works because the public and private key have an unbreakable and inimmitable bond.

All of the following text assumes that you already HAVE a ready-to-use SSH keypair. That's the first step in the three-step poster shown at the top of this page. Generating a keypair is done using the ssh-keygen command, which needs to be run as the account that will be using the keys. Basically: ssh-keygen -t dsa is all you need to run to generate the keypair. It will ask you for a passphrase (which can be left empty). 

 

What if you don't have ssh-copy-id?

Unfortunately ssh-copy-id is not included with every SSH client, especially not if you're coming from Window. Unfortunately, the instructions below will only work when your source host is a Unix/Linux system, so if you're using Windows as a source you will definitely need to use the manual process. The script below also assumes that the remote host is running OpenSSH.

Copy and paste the script below into a terminal window on your source host. It will ask you to enter your password on the remote host once.

==============================================================

echo "Which host do we need to install the public key on?"
read HOST
ssh -q $HOST "umask 077; mkdir -p ~/.ssh; echo "$(cat ~/.ssh/id_rsa.pub)" >> ~/.ssh/authorized_keys"

==============================================================

This could fail if the public key file is named differently. It could be id_dsa.pub instead, or something completely different if you are running a non-vanilla setup. 

Setting up SSH keys the hard way

So, finally the hardest part of it all: getting SSH keys to work, without the use of ssh-copy-id or any other handy-dandy tooling. 

First up, there is the nasty fact that not all SSH clients and daemons were created equal. There are different standards that they can adhere to when it comes to key file types as well as the locations thereof. Because Linux and open source software have become so widespread, OpenSSH has become very popular as both client and server. But you'll also see F-Secure, Putty, Comforte, and a whole wad of others out there. 

To find out which Unix SSH client you're running, type: ssh -V

For example:

$ ssh -V
ssh: F-Secure SSH 5.0.3 on powerpc-ibm-aix5.3.0.0

$ ssh -V
OpenSSH_4.3p2, OpenSSL 0.9.8j 07 Jan 2009

OpenSSH

• All key files are stored in ~/.ssh.
• Key files use the OpenSSH key format.
• By default, the key files are ~/.ssh/id_rsa or ~/.ssh/id_dsa and ~/.ssh/id_rsa.pub or ~/.ssh/id_dsa.pub.
• On an OpenSSH server, your public key is added to the file ~/.ssh/authorized_keys.
• All public keys that provide access to one account are stored in the same authorized_keys file.

F-Secure

• All key files are stored in ~/.ssh2.
• Key files use the SSH2 key format.
• By default, the key files are ~/.ssh2/id_rsa or ~/.ssh2/id_dsa and ~/.ssh2/id_rsa.pub or ~/.ssh2/id_dsa.pub.
• On an F-Secure server, your public key is stored in its own file in ~/.ssh2/$filename.
• $filename is then added to ~/.ssh2/authorization on its own line, prepended by the word "Key".
• All public keys that provide access are stored in separate files and refered to using the authorization file.

Putty and WinSCP

• All key files are generated and managed by puttygen.
• Key files use the SSH2 key format. 
• Keys are stored internally and can be exported using puttygen.
• Putty does not have a server component.

When you are going to be communicating from one type of host to another (SSH2 vs OpenSSH), then you will need to perform key file conversion using the ssh-keygen command. The following assumes that you are running the command on an OpenSSH host.

• ssh-keygen -i -f $file, imports an SSH2 file and converts into OpenSSH.
• ssh-keygen -e -f $file, exports an OpenSSH file into SSH2 file format.

Key points to remember

• On the source host only the private key file is required.
• On the destination host only the public keys are required, stored in the right location.
• The public key file from the source host is only used for distribution.

Always make sure you are clear:

• Who is the source user? On what source host?
• Who is the destination user? On what destination host?

File permissions

• In all cases your homedirectory ~/ permissions may not exceed 755. Groups and others should NOT have write access.
• In all cases the SSH directory (~/.ssh, ~/.ssh2) permissions may not exceed 700.
• In all cases the files in the SSH directory (~/.ssh/* or ~/.ssh2/*) may not exceed 600.

kilala.nl tags: work, sysadmin,

View or add comments (curr. 1)