SSH keys

From MCS IT Wiki

A note about this document: Since the purpose of this document is to get you connected via an SSH session to a unix host, we assume at least a passing familiarity with command line unix, copying, pasting, and ssh.


Contents

Using SSH keys in MCS

This page outlines the steps required to get your SSH keys in place to use MCS workstation resources via SSH. We have tried to cover as many situations as is reasonable, but obviously, problems can occur. We have to handle a lot of these key installations in the regular operations of things, and more when there's a large influx of people. So we ask that you read over this information and, where appropriate, follow the steps outlined to get operational. If you do encounter problems, you can always ask us for help at help@cels.anl.gov.

Note: If you are using a registered host (the hostname ends with .mcs.anl.gov) on an MCS network you do not *need* to use keys to access MCS workstation resources.

SSH is the main method that MCS supports for people to use to connect to MCS unix machines remotely.

When connecting to an MCS unix machine, you will need to provide information that demonstrates you are who you say you are. This is traditionally done by providing your username and your password. However, this is not quite secure enough, and so MCS is requiring that other methods be used. SSH supports several different methods, one of which is the use of "keys".

Without going into the details of the protocol, this document will describe what you need to do to get your SSH program to use keys. This will involve generating and installing keys. Once these are in place, you can also use "agents" to reduce the number of times you need to type a password.

Keeping Your Keys Safe

What's a Passphrase and why do I need it?

Because the private key you generate is so important and powerful, you're given the option of encrypting it with a passphrase. The passphrase is the combination lock to the super-secure safe in which the key is kept. Only you should know that combination, and it shouldn't be one that's easy to guess. When it comes to us, MCS requires the use of strong passphrases.

A passphrase is like a password, except it's not a word, it's a phrase. That sounds kind of simple, but think about it -- when you assign a passphrase to your key, you are given extraordinary flexibility and freedom in what you can use. If someone gets hold of that key, they're going to try to break the combination, but all they can do is keep trying different ones. If your passphrase is redwood or monkey or ball, they're going to crack it in a matter of seconds. If your passphrase is golf7tango or pq0dd8jk or sk#$a02!, they're going to crack it in a matter of minutes. But if your passphrase is I have a *wonderful* chihuahua who is 7 years old!, that's not going to get cracked in any reasonable period of time. If your passphrase is TbXplvPgyPDzsLHw28dbYVNNM+R3uw1wg/f0VC/hsDQ lyWVbEEm RZns lU48bX9T wH2jq0Mw 0 6 V3sIPrcocogl3wG YI2s5CF0QNBq8mbhEx69t FlyJoRJzv/ZxS7IvOWs63Ok4RUP6QwBlyJu8qYgtuPwSIXeW6ic, it's probably safe for a lifetime, but who's going to remember that?

The nice thing is the simple sentence with some punctuation and numbers is very difficult to crack, but if chosen correctly is very memorable to you. You probably won't even need to write it down.

The key thing to remember is this: length beats complexity. Choose something memorable and strong and your key is safe. And if you use an agent, you'll only have to type it once a day or so.

Where should I keep my private key?

In general, your private key should live only on a system to which you, and no (or very few) other people have access; for example, a local directory on your workstation in your office or home, or your laptop. In general, putting a private key on a system to which many other people have access isn't advisable. This includes putting them in your home directory on an MCS workstation, since your home directory is shared across all systems.

If my private key is needed to login as me, and I keep my private key protected, why does it need a passphrase?

If it were absolutely, completely, and 100% guaranteed that your private key couldn't be grabbed by some unauthorized person, it would probably be OK to live without a passphrase. However, there have been situations when even laptops and single-user workstations have been broken into, which means that you can't be totally certain that your private key is completely safe. Having a passphrase adds one more level of protection. Think of this as analogous to your ATM card: To withdraw money from an ATM, you need the card itself, and you need to know your PIN. You're unlikely to lose your ATM card; but if somebody stole your wallet and your ATM card were PINless, the thief could use it to withdraw cash from your account. Just as a PIN prevents your card from being used by an unauthorized person, giving your SSH keypair a passphrase prevents your key from being used if the private key gets stolen.

In short, storing a private key on a system or fileserver used by many people is a bad idea. And having an un-passphrased key is a really bad idea. And having an un-passphrased private key on a public server is a really really bad idea.

But I need to have an un-passphrased key, because ...

There are situations where giving a key a passphrase will cause difficulties, because an ssh connection needs to be established by some non-human entity which isn't able to provide the key's passphrase; for example, a cron job, or something run by CGI script on a webserver. So in situations like that, an un-passphrased key might be the only solution; but there are ways to mitigate the risk:

First, ensure that the keypair used for this is used only for this particular application, and that the private and public keys are installed only on the necessary systems.

Second, on the system to which the ssh connection will be made, use the command= and/or the from= features in the line of your authorized_keys file which contains the public key corresponding to the un-passphrased private key. The former will cause the specified command to be run when a connection is made using that key (i.e. will limit those connections to run only that command and nothing else); the latter will restrict the hosts from which connections using that key can be made. For example:

bongo> cat /home/bozo/.ssh/authorized_keys 
ssh-rsa AAAA[rest of key]UR8= foo@bar
command="/home/foo/bin/kazonga",from="login.baz.org",no-port-forwarding,no-agent-forwarding,no-X11-forwarding,no-pty ssh-rsa AAAA[rest of different key]yGhs= foo@barbaz
bongo>

The first of the two public keys corresponds to the keypair generated on foo's laptop (named bar); Foo gave it long, hard-to-guess passphrase, and the key can be used to login for an interactive session on system “bongo”.

The second public key is the one that matches the unpassphrased private key on “bongo”; but if that private key is used, the connection has to come from login.baz.org, and it will run Foo “kazonga” script rather than setting up a login session. And that's all it will do. If someone were to get hold of that key, the only task they could accomplish with it is run "kazonga" on "bongo" from "login.bar.org", and nothing else.

That's the only acceptable way to implement a passphraseless key in MCS. Full details on what type of restrictions you can put on the key can be found by typing man sshd and reading the chapter on authorized_keys file.

What if I ignore this advice?

We are regularly scanning all our systems.

  • Any keys without passphrases are collected, and we test the public keys on these against the authorized_keys files across the system. If we find an unacceptable use of them, we'll remove the offending public key and add it to a list of known passphraseless public keys.
  • We are also trying to break into keys at regular intervals. If you have a good passphrase, your key is practically uncrackable. If you have a lousy passphrase, we can crack the key in minutes. If we crack the key, we'll test its public key against all authorized_keys files for unacceptable uses and will add the key to a list of known weak public keys.

In each case, we'll notify you if we find something. Repeated infractions would result in a loss of SSH privileges.

Creating your keys

You will need to install SSH keys on the machine that you use to login to MCS. This may be your laptop, your machine at home, a desktop at some other site, or any other computer not in the MCS UNIX space.

Follow the instructions below based on the kind of system you're using.

Uploading your public keys

To upload your SSH public key, visit https://accounts.mcs.anl.gov/ and click the "Add New SSH Public Key" button next to Credentials in your account record. Your keys will be installed automatically within 15-20 minutes.

Personal tools