SSH Private-Public Key Auth for Linux and Mac

First Things First

First off, let’s talk about SSH keys and Security real briefly so that you can understand a bit more about what’s going on here and why it’s important. With all the issues happening in today’s digital age, everyone needs to start thinking about and taking one thing very seriously. You know, all the hacking and spying going on around us all.

One of the ways you can accomplish that is by using stronger encryption methods, in this case … SSH Keys or Public Key Cryptography. One of the major things is the key size. 1024 was common but that has long been hacked and not used anymore for websites and other public; so logically many are moving on to 2048 and even 4096, which is what I use.

SSH Keys provide a much more secure way to log into your servers than using passwords. While passwords can be easily broken by brute force attacks, SSH Keys way more difficult and if using a higher key can be almost impossible to decipher.

How does it work?

Generating a key pair provides you with a Private and a Public Key. You place the public key on a server you will connect to leaving the private key on your machine. When you SSH to your server you will not need to enter your password as your public key will be unlocked by your private key and you will be verified and allowed to get in.

Generating Your Key Pair

Private keys should ALWAYS be kept as geographically close to the authenticating user as possible (such as your local desktop/laptop, or for those truly paranoid, a removable/wearable USB dongle).

Note: Given there has been significant computational advances in cryptography, keys should be a minimum of 2048 bits in size. For very strong RSA keys, use a key size of 4096 bits. Since DSA uses a fixed key size of 1024 bits, it is no longer considered secure. Do not use DSA.

Generating public/private rsa key pair.

To start the process, type in the following

ssh-keygen -t rsa -b 4096

You will be prompted with something similar to the following:

Enter file in which to save the key (/Users/username/.ssh/id_rsa):

I leave mine in the .ssh directory but if you want to put your somewhere else, just change the path.

Next you will be prompted to enter a passphrase, enter a good secure password here (you will not enter this password often if you choose to run the SSH agent).

Warning: This is a vital step in securing your private keys from attackers/prying eyes. Without a passphrase, your key can easily be duplicated and used by unauthorized people without your permission.

Enter passphrase (empty for no passphrase):
Enter same passphrase again:

Your key will be generated and you will see output like:

Your identification has been saved in /Users/username/.ssh/id_rsa.
Your public key has been saved in /Users/username/.ssh/id_rsa.pub.
The key fingerprint is: 5a:28:e0:5a:91:9b:e5:33:b6:8b:68:51:f8:f7:c9:71
The key's randomart image is:
+---[RSA 4096]----+
|+B+..            |
|B.oo .           |
|.B.+ +           |
|o E .o o         |
|..    + S        |
|       o .       |
|        . .      |
|         .       |
|                 |
+-----------------+

Please note the file permissions of both of these keys.

ls -l .ssh/
total 16
-rw------- 1 username username 3326 Aug 1 15:54 id_rsa
-rw-r--r-- 1 username username 743 Aug 1 15:54 id_rsa.pub

In order to use your SSH keys for login to a remote host, you first need to copy your public key to the remote host. This is as easy as copying the id_rsa.pub to the remote host and appending the file’s contents to your ~/.ssh/authorized_keys file.

Warning: Do not copy your private key to a remote host.

For Debian/Ubuntu users, there is a utility to do this for you.

ssh-copy-id -i ./id_rsa.pub user@remote.host

or you can copy it over using SSH

cat ~/.ssh/id_rsa.pub | ssh user@servername "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

Setting up an SSH Agent

A SSH Agent reads private keys into memory and allow them to be used without having to retype each key’s passphrase. This process varies by distribution/OS but should be available on all modern operating systems.

Setting up an SSH Agent on a Mac

MacOS X includes a simple mechanism to integrate existing SSH keys into the OS–level keychain.

You should import your private key into your Mac’s keychain:

ssh-add -K ~/keys/id_rsa

After your system reboots (or, presumably, on next login), your key will then be loaded into your user environment. Once rebooted, you can verify this by running:

ssh-add -l

Setting up an SSH Agent on Linux

Ubuntu/Debian now seem to be supporting ssh-agents via dbus as part of Xsession startup or built–in directly to your window manager. When in doubt you can always use “keychain”.

sudo apt-get install keychain

Add the following to your startup script (~/.profile or whatever your shell uses):

# Run Keychain..
keychain_bin=$(which keychain)
keychain_host=$(uname -n)


# List of keys to load by default
keychain_dflt_keys=""
[[ -x ${keychain_bin} ]] && ${keychain_bin} -q ${keychain_dflt_keys}
[[ -f ~/.keychain/${keychain_host}-sh ]] && source ~/.keychain/${keychain_host}-sh

Make sure to add the path to your key in keychain_dflt_keys, like this:

keychain_dflt_keys="/Users/username/.ssh/id_rsa"

Once we have an SSH Agent running we can use the ssh-add command to check for identities (private keys). List all the private keys loaded into the SSH agent:

ssh-add -l

Lets add our newly created private key, you will need to add your private key to the ssh-agent. (this should prompt you for your password only once)

ssh-add ~user/keys/id_rsa

Once this is done you should be able to login without entering your password to any host/cluster you have placed your public key on.

Setting Up SSH Agent Forwarding

Make sure you have enabled ForwardAgent=yes in your SSH config (~/.ssh/config) which will forward your agent through the SSH connection for each connection, allowing you to connect to a host through another host (e.g., a jump box). The other option is to invoke ssh with -A option. Your private key should only remain on the host where the key was created (i.e., your local system).

Updates

Below you will find extra things that I am configuring as I learn more or as things change security wise.

Config changes

The following configs are done in the sshd_config file. As you know, I use vi but you can replace that with any editor you’d like.

sudo vi /etc/ssh/sshd_config

Make sure the following exist and are active:

Only use protocol 2

Protocol 2

Limit Idle Timeout

ClientAliveInterval 300
ClientAliveCountMax 0

Disable root login

PermitRootLogin no

Disable empty passwords

PermitEmptyPasswords no

Hide SSH Version

UsePrivilegeSeparation yes
StrictModes yes
VerifyReverseMapping yes
AllowTcpForwarding no
X11Forwarding no
PasswordAuthentication no

Additional Security

Here are additional things you can do to secure your server via SSH.

Fail2ban

Fail2ban is a program that prevents brute force attacks against SSH.

Advertisements