From the POV of an advanced *nix user setting up public and private keys for password-less SSH logins seems trivial. However, to a beginner/novice user this can be confusing. I’ll admit, as comfortable as I am with managing Linux servers, configuring RSA keys on the local and remote machines was messing with my head – until I got the hang of it. I still don’t have a complete top-to-bottom understanding of this when it comes to different versions of SSH and then some, but enough to jot down a note for future reference just in case. I’ll assume the reader has a basic knowledge of CLI, connecting to a remote server with SSH, and that the two (or more) devices in question are both Linux machines.
By the way, there are a lot of these guides out there, but i couldn’t find one that helped. I still had to screw around a bit to really the the hang of it. They were either all too in-depth, too brief, only covered certain parts, or simply just didn’t fit my needs.
Before we get started, there is an easier and less intrusive way to do this if you’re running cPanel. I’ll write about that later.
Close your eyes, find your power animal – slide… imagine you’re logged into some nix box (we’ll call this one “foo.com” with user “jack”). Now you need to issue some commands on another remote machine (and we’ll call this one “bar.net” with user “jill”), so what do you do?
[firstname.lastname@example.org ~]$ ssh email@example.com
At this point, it will make the connection, and if is the first time ask if you want permanently trust the connection, in which you reply “yes” after careful consideration. SSH prompts you for a password, you type it in and you’re good to go. You start navigating the filesystem and ferociously execute commands.
Now this scenario is all fine and dandy, until you’re accessing the server so often that you get sick and tired of typing your 15 character password (with upper/lowercase letters, numbers and symbols). Perhaps a better excuse to not enter the password is that you have a non-interactive shell script that needs to make this connection temporarily, in which case you do not have the luxury of entering your password in the prompt; don’t even tell me you were thinking of embedding the password into the command with the p switch. Wish there was a better way? Let me show you the light.
Benefits of Using Keys with SSH
- Doesn’t prompt for a password (duh)
- Can be used with non-interactive/unmonitored scripts (play off of the previous bullet)
- FAR more secure – this is probably the biggest reason you should be going with this approach regardless of the previous benefits
- Establish a “trusted connection”
- Help prevent brute force attacks
- Read this article on “old” password-style authentication
Remember jack and jill on foo.com and bar.net? Well they didn’t fetch a pail of water, instead they generated an RSA key with ssh-keygen. We’re getting back to that now… There are two types of encryption: DSA and RSA. DSA is supposedly faster but not as compatible (isn’t compatible w/ Protocol 1). RSA has higher encryption (4096) and is more compatible, but at the cost of speed. Up to you, but i’ll be sticking with RSA.
Configure SSH and SSHD on foo.com and bar.net
- Make sure that ssh is configured correctly on foo.com and bar.net: Use Protocol version 2, not 1 (you can use 1, but it is a PITA especially when you’re configuring multiple keys)
- On bar.net in your sshd configuration (e.g., /etc/ssh/sshd_config) you’ll need the following configurations:
123RSAAuthentication yesPubkeyAuthentication yesAuthorizedKeysFile .ssh/authorized_keys
- All other defaults (OOTB) should be good, maybe when you’re done you can set “PasswordAuthentication no” within bar.net’s sshd_config to force the usage of only key exchanges.
Generate a Key Pair on foo.com for Jack to Use
- Create a .ssh directory in jacks’ home directory if it doesn’t exist yet, /home/jack or ~/ if you’re logged in as jack. actually from here on out, just assume you’re logged in as jack, if not, make sure you can sudo -u jack to make it seem like jack is issuing the commands. mkdir /home/jack/.ssh
- chown jack:jack /home/jack/.ssh
- chmod 700 /home/jack/.ssh
- step 3 is important, make sure the perms took: stat .ssh
- ssh-keygen -t rsa -C “the key for jill on bar dot net”
- the t switch tells ssh-keygen what crypt to use (t = type) and the C switch is just a comment to leave in the public key string (c = comment)
- Hit return
- Now it starts to generate a public/private key pair and asks you where to save giving you a suggestion (default): /home/jack/.ssh/id_rsa
- id_rsa is the default and you can stick with that, but if you want to store multiple, you’ll have to outsmart the keygen. remember, the computer is just a tool, its faster than you, but not nearly as smart. you need to be smarter than the computer if you’re not, this is a requirement unless you’re competing against an IQ of 150. before you hit enter, read step 10
- save it to the file: /home/jack/.ssh/id_rsa.jillbarnet
- take a moment and think, who is Jill Barnet?
- when prompted for a passphrase just keep it blank and hit return (twice)… disclaimer: this is NOT really a good idea. you should always have a passphrase for security purposes, but i’m lazy right now and don’t wanna go through the extra steps, if you’re really worried RTFM.
- notice /home/jack/.ssh/id_rsa.jillbarnet and /home/jack/.ssh/id_rsa.jillbarnet.pub
Configure Jack’s Account to Use Multiple Key Pairs
This is important if you followed the last steps exactly. We generated a specific key file. By default, ssh looks for a file called id_rsa. If we wouldn’t have specified a file, ssh-keygen would’ve written to that default id_rsa file and loaded it by default every time. This sucks when it comes to managing multiple keys, so forget the default functionality; we’re gunna rock this bitch.
- Create a file called config: touch /home/jack/.ssh/config
- chown jack:jack /home/jack/.ssh/config
- chmod 600 /home/jack/.ssh/config
- edit the file (i like nano, sorry @ most of you vi snobs): nano /home/jack/.ssh/config
- For each id_rsa.* entry we’ll need a Host and IdentityFile directive, all directives separated by at least a new line…
The Host directive means that only the next line (IndentifyFile) is applicable when connecting to that specific host. The IdentifyFile directive describes what file to use in that situation. So lemmie pick this apart really quick. I indent because it looks pretty.
- Lines 1 and 2 mean that ssh should use the file id_rsa.jillbarnet when connecting to host bar.net.
- Lines 3 and 4tell ssh to only use file id_rsa.rickybobbyorg when connecting to bobby.org (where did he come from? read the next section and find out)
- Lines 5 and 6 is basically a catch all. The asterisk is a wildcard, it means, for any host that hasn’t matched yet, use the default identity id_rsa.
Hint: If those files don’t exist ssh won’t crap out at all, it’ll die gracefully during the lookup and continue normal operations (and ask for a password). So no worries there.
In theory you could combine multiple identity files under the same host directive, but i haven’t tried it and don’t take my word for it. You can also wildcard partial host names, e.g. Host *.domain.tld – this i did try.
Understanding the Private Key and Public Key
So here’s the confusing part, really try to pay attention. Remember step 13 (scrunched together letter B) in previous? Why did it generate two files when you only specified one?
Well this is where private key and public key comes into play. The private key is “id_rsa.jillbarnet” and the public key is “id_rsa.jillbarnet.pub”. The private key STAYS with Jack on foo.com, it should never be shared, that’s why it is “private” you I-D TEN TEE. The public key is the one you can whore out to other accounts; i’ll squash the myth right now: the public key is not specifically for jill over at bar.net, it can be used for ricky over at bobby.org, or at both places (firstname.lastname@example.org and email@example.com). The public key simply acts as a “trusted” or “authorized” user who provides the private key. Read that last sentence two or three more times.
The private key looks something like this:
-----BEGIN RSA PRIVATE KEY-----
....stuff here....more stuff........................
-----END RSA PRIVATE KEY-----
And the public key looks something like this (a command with a base64 encoded string + your custom comment):
ssh-rsa AAAAB3NzaC1yc2EAAAA...lots of characters...HKk3uaQ== the key for jill on bar dot net
Cool? Cool. Now let’s prep jill’s home dir.
Prep Jill’s Home Dir Over at bar.net for Jack’s Key
Let’s assume jill’s home directory is /home/jill. Again assuming you’re logged in as user jill and jill belongs to group jill (in previous i assumed jack belonged to group jack).
- Make sure jill has a .ssh dir in her home directory, if not make one: mkdir /home/jill/.ssh
- Verify jill is the sole owner: chown jill:jill /home/jill/.ssh
- Make sure jill is the only one allowed to access that .ssh directory: chmod 700 /home/jill/.ssh
- make a file called authorized_keys: touch authorized_keys
don’t know what touch does? RTFM: man touch. (just wanted to type “man touch”)
- set restrictive perms (that’s permissions, not a hair-do) for authorized_keys: chmod 700 authorized_keys
- At this point, in some envs/distros they require an authorized_keys2 file, just make sure it is identical to authorized_keys in terms of content and permissions. Or in my case with CentOS5, you don’t need it. so skip this step. I experienced this issue on a Debian box, fyi.
- Copy the contents of id_rsa.jillbarnet.pub (the one with the content that starts “ssh-rsa” then has the base64 encoded string w/ the comment) and append it to authorized_keys. There are a million-n-a-half ways to do this. Figure it out.
- For multiple entries in authorized_keys, just delimit them by new lines. so each line will start with “ssh_rsa”
- I feel like i’m forgetting something, but that should do it.
Test From Jack’s Account on foo.com
[firstname.lastname@example.org ~]$ ssh email@example.com
Granted you did everything correctly, it will log you in w/o a password prompt. If it asks for a password, you screwed up somewhere, try again, do not pass go, do not collect 200 bones. Note that restarting SSHD will NOT solve your problem, no service restart is required.
That’s All She Wrote
Well that’s it. So now you can connect to multiple hosts using multiple private keys for jack at foo.com (using multiple id_rsa files and the config file updates), and multiple people can connect to jill over at bar.net (by copying the public key to authorized_keys and delimiting by new lines). Any questions? Too bad, I closed my comments.