The target audience for this entry is “people using OS X who don’t have a lot of UNIX shell experience”, though it might also be applicable for people learning the basics of any UNIX-based or UNIX-flavored operating system, barring some minor differences in where binaries, configuration files, etc., are located in the particular file system. What we’re going to describe is the basic process for creating public and private key pairs for use with SSH, or “Secure SHell”. But first, let’s talk a little bit about what SSH is.
SSH is a client/server protocol which allows a user on a “client” system, to securely log in to a “server” system. In this context, the “client” system would be the system you’re reading this article on, and the “server” system would be the (most likely) remote system you want to login to. Keep in mind, the “client” and “server” can actually even be the same system, as “client” in the context of SSH just means the machine you launch the ssh process from, and “server” means the system running “sshd“, the server piece of SSH, which allows encrypted remote login.
Client (ssh) -> Server (sshd)
Basic use of
ssh/sshd requires that an account exist on the server you want to login to, and that you know the user name and the password for that account. It also requires that SSHD be running on the server, and that the particular port SSH is configured to use be open to the segment of any given network you’re on.
First, your account has to exist in both places (client and server). For the purpose of this instructional entry, we’re using an example user name of “username“, the details of which look like this:
Login: username Name: username
Directory: /Users/username Shell: /bin/bash
Never logged in.
In order to keep this basic, we’re going to assume you have two systems; a MacBook Air (macbookair.local), and a Mac Mini (macmini.local), both sitting on your home network. Provided you’ve created accounts for yourself (in this example, each has a “username” account), and you want to login from your MacBook Air to the Mac Mini, what you’ll want to do next is make sure SSHD is running on the Mac Mini. You can do that through the GUI (go to System Preferences::Sharing and select the Remote Login option, turn it on, and select that it allow “All users” to login remotely):
Or you can turn it on from the command line, by issuing the following command in a terminal window on the Mac Mini, from an account with “Administrator” privileges (because it turns on a system service, it will require an administrator password be entered):
sudo launchctl load -w /System/Library/LaunchDaemons/ssh.plist
At this point, you should be able to use
/usr/bin/ssh) to login from the MacBook Air by simply typing “
ssh macmini.local” or whatever the host name is for the server.
macbookair:~ username$ ssh macmini.local
The authenticity of host 'macmini.local (192.168.11.35)' can't be established.
RSA key fingerprint is SHA256:A+aZMhz8Sk+tteMTOYevHEJVthI4B0fXzQ5tUr9+cbw.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'macmini.local,192.168.11.35' (RSA) to the list of known hosts.
Password: [username's password]
And boom, you’re in. Simple, right? Well, typing a password once isn’t too bad, but if you do this a lot, you’ll want to avoid having to type that same password all the time. SSH Keys allow you to circumvent the need for typing the password, as it enables the use of a public/private key pair to authenticate that 1) you are who you say you are, and 2) you should have access to where you’re trying to login.
The next thing to do is generate a pair of keys, using “
ssh-keygen“. From the MacBook Air, issue the following command:
macbookair:~ username$ ssh-keygen -t rsa -b 4096
ssh-keygen can actually be run without the command line arguments shown, but since anything worth doing is worth doing right the first time, I’ve added each argument for the following reasons:
-t rsa‘ tells ssh-keygen to generate a key using the RSA-specific algorithm. I prefer this algorithm for my own personal reasons, which I’ll discuss some other time. For now, you can either use it, or you can use the default algorithm, or any of the other options.
-b 4096‘ tells it to make the key-pair with a bit length of 4096, rather than the default of 2048. With public/private keys, the longer the bit length, the more difficult it is to decrypt the data.
Issuing the command will result in the following:
Generating public/private rsa key pair.
Enter file in which to save the key (/Users/username/.ssh/id_rsa):
Created directory '/Users/username/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
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:
The key's randomart image is:
| +.. |
| . + . o . o . |
|. + o B = o . E |
| o . = @ + +.|
| . o B S . .o|
| + o + o o . .|
|o o o . . . |
|o.o..= . |
| ++=+ . |
You’ve now successfully generated an SSH key pair. The key pair has two elements; the private key (
id_rsa), and the public key (
id_rsa.pub). They’re both located inside the
.ssh directory inside your home directory (unless you specified that it place the keys somewhere else when you were generating the key pair). The
.ssh directory is accessible from the command line (
cd ~/.ssh/ will place you there), but should be “invisible” from a Finder window, as Finder hides, by default, any directory that begins with a ‘.’ character. So the two files we just created are here:
~/.ssh/id_rsa= PRIVATE KEY
~/.ssh/id_rsa.pub= PUBLIC KEY
Now, I’m going to over-simplify the description of how key pairs work, because the reality is a little math-heavy, and you don’t necessarily have to understand it in order to benefit from their use, but basically, the
id_rsa.pub file contains information that allows data to be encrypted that should only be decrypted by people with access to the contents of “
What you DO need to remember is this: KEEP
id_rsa TO YOURSELF. Never transfer the contents of
id_rsa to another user, another system, or anywhere you don’t plan on keeping entirely secure.
id_rsa.pub is distributable to systems where you want to login in order to access them remotely, but
id_rsa is not to leave your system. Defend it with your life, because if someone else gets a hold of
id_rsa, they will then have password-less access to everything you have access to, and that can be bad. Very, very bad.
Now, let’s take a look at the public key (
id_rsa.pub) we just generated:
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQCzSwBZ6AT9gQYV3m1OAKRJpoktxn8RuoubIp1mkaJvSBYw/zS7UCGFyKVwlbzr88HU9ddlFRd0EZKRqUFbbMBoqwt0G/EPhp4Rs4L2wkDbOZkUJLaGHlEflwn4iVHK6Y3BXOppIRWu0u8aTWKsOyxmv3DCKhAr6HDfxhYQJ+egkWN9Qhz1em1PSqPV/d6bujgrD0SUZpP7Kz2V4nSvc9jGUhtOaCMwAxuDc66j5xpT8j+nEiGx8KdzJHBDwQm/aBqDmVj+G/Lchq8C1147iAw1W8RYoQXfDJyFK/CNIgz0uPi2UdUumNOxsASH0C76kXQAC3Lrjsdf6b+MJ1LJQIQ28msRTiRxc+b1O10SylEb/SEikRnngqbhwiFQU0f95RLWBrSpfw1RRWCOZxovH12+/R4CmeDm3D3fajU9Gapi6EnPlNl3mrEK1GlaE/8TS0BMa4jHGWx1sppxD8e11yyaFyEeYPF5VePnV7pO7bDrreZQJVWP0ldp5suVMDLm2Ggx8SEWD3+JTWwwhRaZyDNh9BxQaD34AHdsb326q1+N3vU7UxugXFdtejU8aGZCKI40VQhLij2lZbPiPQzBwAvBoyfFjo3CYRVhGN0CxvKqhA2Sz4F6/N/eHt5UPJsf0eyiJKvc75g3nNqOUKDeImpm3sSdldghTXhDpbObg7mpeQ== email@example.com
The first seven characters establish that this is an ssh key, generated with the RSA algorithm, then there is a long sequence of characters that do not appear to be human-readable, followed by “
firstname.lastname@example.org” at the very end, which means that this is the user who generated the key, and the hostname it was generated on was “
What we need to do next, is copy this key over to the Mac Mini, and put it in “username”‘s
~/.ssh/ directory, in a file called “authorized_keys”. The simplest way to do this from the MacBook Air is going to be by using “
scp” to send it there.
scp .ssh/id_rsa.pub macmini.local:~/.ssh/authorized_keys
What this command does is tell the “
scp” (secure copy) process to send file “
.ssh/id_rsa.pub” to the host “macmini.local”, where it should save the file as “
.ssh/authorized_keys” on that host. Issuing the command will result in you being asked for username’s password on MacMini (one last time!), to authenticate that you have access and privileges to write files as username on the Mac Mini, then it will copy the file, and save it on Mac Mini with the filename “
authorized_keys” in the
Now, what you can do is try to login from your MacBook Air to your Mac Mini again, using
macbookair:~ username$ ssh macmini.local
Provided it worked (and why wouldn’t it have?), it should have just logged you right in without pestering you for that pesky password. And now you’re cooking with gas!
In future articles about SSH and scp, we’ll get into some more depth of what is possible, including using scp to copy entire directories from one machine to another, using ssh-agent to allow forwarding of credentials from one host, to another host, to another host, and securing access to SSH to specific groups of users, as well as using non-standard ports to confuse potential attackers. There is a lot that can be done with this family of tools. For now, pat yourself on the back for what you’ve accomplished, and go get some coffee!