ssh passphrases and ssh-agent exercise

If you do this exercise in the gnome desktop environment, using terminal windows, first see below under  "Disable keyring daemon SSH component".  Do what it describes. gnome autostarts a copy of ssh-agent that will interfere with this exercise. Either disable as per below, or do the exercise altogether outside a gnome environment  (e.g., in virtual terminals or in terminal windows opened under some other desktop environment or window manager, not gnome.

Disable keyring daemon SSH component

In case if you run your own version of the SSH agent (e.g. ssh-agent), you need to disable the SSH component in GNOME keyring daemon:

 ln -sf /dev/null /etc/xdg/autostart/gnome-keyring-ssh.desktop

Then you need to logout to make the effect. That means close the GUI entirely ("log out") and start it altogether afresh ("startx"). Gnome will now come up without it's own built-in ssh-agent, as we desire.

from  https://wiki.archlinux.org/index.php/GNOME_Keyring#Disable_keyring_daemon_SSH_component

 



Please read and heed the box above, before you proceed or this exercise won't work.

This exercise presupposes that you understand how to set up passwordless authentication to a remote machine with ssh by key placement, and that you have done so by performing this ssh key setup exercise. In that exercise you enabled yourself, when operating as "student" on your local machine, to skip the password challenge when logging in on the remote machine as student01 (you were assigned such a remote account to use as login target; studentXX where XX was a 2-digit number). Here, "student01" is representative. Wherever you see "student01" in these instructions please substitute the actual remote account which you used when you did the key setup exercise.

ssh-agent manages the passphrases on ssh private keys. But you can't use it because you didn't put a passphrase on your private key when you did the key setup exercise. So in order for ssh-agent to have something to manage, we need now to retroactively put a passphrase on the private key of local machine's "student" account. That private key is /home/student/.ssh/id_rsa .


Place a passphrase on the existing private key of user "student"

Login locally to your classroom workstation as user "student". Verify that the setup you created when you did the key setup exercise there is still in place and working. Do so logging in to the remote account with ssh:

ssh student01@<server address>

Note the successful login and, in particular, the absence of a password prompt when doing so. Get back out of the remote account/machine and back to the local account/machine:

exit

You did not get a password prompt for the remote student01 account because alternative arrangements have been made (key placement). Neither did you get a passphrase prompt (not the same thing!) because no passphrase was ever placed on the local private key. Back when you did the key setup exercise, the instructions told you to ignore the prompts for creating a passphrase. So none exists. But we can apply one now, retroactively. passphrases apply to ssh private key files. Yours is /home/student/.ssh/id_rsa (or id_dsa, if so use "dsa" in place of "rsa" in the following instructions). Let's add a passphrase onto your (local user student's) private key:

cd  /home/student/.ssh
cp  id_rsa  id_rsa-no-passhrase   [ keep a copy of the original passphrase-less private key  ]
ssh-keygen  -p  -f  /home/student/.ssh/id_rsa   [ give the word "passphrase" as the passphrase when you are prompted for one ]
 cp  id_rsa  id_rsa-with-passphrase   [ keep a copy of the new passphrase-ful private key  ]

Observe that the private key has been changed by noting differences in the file sizes:

ls  -l  id_rsa-no-passphrase
ls  -l  id_rsa-with-passphrase

More specifically, note the difference by examining the first lines of each file (they are ascii-encoded):

head  id_rsa-no-passphrase
head  id_rsa-with-passphrase

The file with a passphrase has a header including "DEK-Info." DEK stands for data encryption key. Note also the ascii-encoded bulk of the file's content is also different. Why?

So what's a passphrase?

A passphrase is in effect a symmetric encryption key. It mitigates a vulnerability in the storage of ssh keys. The vulnerability is the possibility that your private key be used by somebody other than you. Preventing that is normally achieved by having you be the person to generate your own key pair. The moment after you do that, you're the only one who has the newly minted keys. As long as you don't let somebody else have access to your keys it will stay that way. While meaningful use of your private key depends on your keeping it in your sole possession, that's totally easy since your private key begins life in your sole possession so to keep it that way you need do nothing. It will sit within your home directory as file .ssh/id_rsa where its permissions will prevent access by others.

Except, if an attacker gains root access to your machine. The attacker can then read and use the key, masquerading as you.

This is the problem for which a passphrase is the solution. A private key stored without a passphrase is ready-to-use. But since it's just a chunk of data it's subject to being encrypted. If so, somebody who comes upon it won't be able to make use of it till decrypting it. If he can't do that, having the private key file doesn't give him the private key itself.

What the passphrase does is to serve as a symmetric key (apart from the public/private ones we're talking about, additional to them) for encrypting the private key file. If ssh sees that the private key file is encrypted, it recognizes that it can't do its job so it prompts the user for the passphrase, then decrypts the private key and goes to work. But the attacker doesn't know the passphrase, and it isn't stored anywhere on the disk for him to find.

Compare this to how user account passwords are treated. They are stored on the disk, just like ssh private keys. But they are stored scrambled, unlike private keys. If passwords were to behave like the ssh key setup exercise's private keys, they would be stored in plaintext. The actual password would appear in the /etc/shadow file instead of the hashed version of it. Can you imagine? That's unheard of and nobody would consider it acceptable. But the key generator "ssh-keygen" lets us not scramble our private keys, storing them plain. That's unlike the password generator "passwd" which unconditionally scrambles our passwords, storing them hashed.

They sound similar and are used in conjunction, but passwords and passphrases play different roles.


Now let's switch private keys, making sure to substitute the passphrase-ful one for whichever one it currently in place:

cp  id_rsa-with-passphrase  id_rsa

Again try an ssh login to your remote account on the remote machine

ssh student01@<server address>

This time, you are prompted for the passphrase. You must supply it to get logged in. But once you do, you're in. (Separately, you don't get prompted for the remote account's password. But you knew that. We took care of it in the key placement exercise already.) 


Use ssh-agent to provide the passphrase when it's needed, doing so transparently and automatically for you as your agent

If you liked the nifty ssh key placement feature that you no longer needed to give the target account's password (you still don't), this might feel retrograde. Because now you still have to remember and manually type something, the passphrase in this case. What if you don't want to get prompted for that either? You can use ssh-agent:

ssh-agent /bin/bash

ssh-add  /home/student/.ssh/id_rsa

You will be prompted for the passphrase that's on your private key. Supply it. ssh-add will store/cache it (plain, in memory). Thereafter ssh-agent can retrieve and apply it for you when you would otherwise have to do so manually. Ask ssh-agent to list "fingerprints of all identities currently represented by the agent," i.e. all the passphrases that it's got cached:

ssh-add  -l

Now again try an ssh login to your remote account on the remote machine

ssh student01@<server address>

This time you get no passphrase prompt. ssh-agent goes to bat for you and the passphrase is applied (i.e., the private key is made available by decrypting it) unattended. This will happen every time you use ssh. You only supply the passphrase once, to ssh-add, instead of multiple times, to ssh. That's the convenience.

Is this permanent? It's as permanent as memory storage. Since the passwords are stored in memory only, they vanish when the machine is turned off. Note also that ssh-agent took /bin/bash as an argument when it was started. ssh-agent runs then it runs bash as a subprocess. When bash exits, so does ssh-agent, taking its cached keys with it. To observe that, collapse your current passphrase-equipped shell and return to the original one from which you came:

exit

Again log in to your remote account and note that, in this shell, providing the password falls to you again since there's no assistant around here (ssh-agent) to do it for you:

ssh student01@<server address>

Finally for future convenience in our tutorial environment, let's restore the passphrase-less version of our private key:

cp  id_rsa-no-passhrase  id_rsa

 

An analogy for passphrases-on-private-keys

You keep a key in your house. Maybe it's the key to your office, or your parents' house, or let's say the storage shed out back. Anybody who gets that key gets access to the shed. And anybody who gets into your house gets access to the key hence, indirectly, to the shed. But you keep your house locked so that's not supposed to occur. Stuff happens in the real world however which, though rarely, includes break-ins of various kinds.

The airbnb guest who occupied your house when you took vacation last summer had your house key duplicated at the hardware store. Now he's back in the house while you're at work. Because he gets the shed key there, he effectively breaks into the shed as well. Within the house the shed key is unprotected and ready for immediate use. Double bummer.

Suppose however you get a very small lockbox with a combination lock on it and keep the shed key inside that. That now becomes what the intruder gets access to. It's the shed key alright, but not in a form available for immediate use. First the combination is needed to get into the lockbox, only then into the shed. Breaking into the house is no longer equivalent, ipso facto, to breaking into the shed. And the combination to the lockbox, unlike the key to the shed, is kept nowhere in the house at all.

Analogs:
house - your computer
key to your house - authentication credentials for accessing your computer
shed - some asset outside your computer, like a remote server
shed key stored in your house - ssh private key to remote server, stored in your computer
lockbox combination - passphrase
hardware store key duplication - some hack that gains allowance to access your computer