SSH - keypair logins
| Security related stuff.
- 1 What a keypair is
- 2 when we like keypairs
- 3 How
- 4 Problems
- 5 Types of setup
- 6 PuTTY
- 7 Remembering keys: agents
- 8 See also
What a keypair is
A keypair refers to a public and a private key that belong together (were generated together).
Practically speaking, we can use it to have one host account trust another host account (usually on a remote host).
...in one direction, and only as long as the private key of the pair is kept secret.
More technically: You can read up on asymmetric cryptography, but the summary is that you can use the public key of such a pair to verify that a message can only have come from knowing the according private key. (It also matters that private keys cannot be inferred from the public one (which is handed around freely), or from encrypted communication.) Note that "can only have come from a specific thing" is also (ab)usable to verify identity verification, whcih is what we do here.
Note that keypairs are, in themselves, just two chunks of data. They are not tied to a person, account, host, use, or anything else until you make it so.
You can generate any amount, so can make them specific-purpose and effectively retractable.
when we like keypairs
Can hinder brute forcing
You can require an account login always supply a key.
This means that instead of a username+password, you now have to log in with username+key+passphrase. This is two-factor authentication: something you have, and something you know.
This means the account doesn't have to worry about the fact that port 22 is open to the entire internet -- because have you checked your auth logs recently? Chances are it's full of Invalid user [...] from [...]" entries. (These are usually purely non-targeted attacks looking for very sloppy accounts like user database, password 123456)
It does mean a user cannot do anything when they don't have their key with them.
Which is why this is usually only done on more critical systems.
(On everyday ones it may still be preferable to tweak the backoff time, or to use things like fail2ban/denyhosts, which will help against naive attacks, though not so much against botnets or specific attacks)
convenient passwordless login
A variant of the last is to require a key, but use no passphrase.
In other words, access with something you have, without something you know.
The obvious downside is that if this is stolen, that means the thief now has access.
So only a good idea
- if the access is a single purpose
- and easily revoked: the are disposable (and you can tell you need to)
- if they are not shared, and unlikely to become so
Uses for passphraselessness:
- a specific host-to-host convenience
- e.g. "I want automatic login to all nodes in the cluster"
- okay because it only has local meaning, and if you have access to the master you would expect access to the nodes
- e.g. "I want my source repository interaction to not bother me so much"
- acceptable when it means access to nothing beyond that repository, and revocation isn't too hard in this case
- also arguable, in that an agent is a more secure solution to this
- e.g. automated rsync-over-SSH backup
- acceptable when fully automated, and storage is isolated per host
- more arguable if used as a "use this to backup" because that way it easily becomes shared
- e.g. automated setup of a SSH tunnel. e.g. for autossh
- arguable, but okay if used for one purpose, and as temporary as that purpose is
- bad if only for convenience. Seriously consider an agent. Even just keeping all passwords under the lock of a single good master password is usually lot better than blind keypair trust.
Sometimes you want to share an account.
Consider group projects - this allows people to allow on people from existing accounts, without needing a sysadmin or other bureaucracy (and less need to explain the fine points of group/permission logic).
Historically, you would share a password. Which has a few problems - e.g. everyone can lock everyone else out.
In this case, keypairs mean:
- can add and revoke access
- ...for individual people if you give them out to individuals,
- ...to groups if groups of people share a key
- you can set it up so that only one person administers which keys are accepted into an account.
Create a keypair
cd ~/.ssh # not necessary, but it's a decent place to keep them ssh-keygen -f my_new_identity #ssh-keygen -t rsa -b 4096 -f my_new_identity # if you care about more security
This generates (you may prefer to give it a name related to its actual purpose):
- the public key: my_new_identity.pub
- the private key: my_new_identity
(You may wish an RSA key things like the answer here)
over the default DSA key. Reasons are nontrivial; security against specific cryptanalysis (in which case you may also want ) is only one, see e.g.
Make a (remote) account trust the public keyIf you have :
ssh-copy-id -i my_new_identity.pub firstname.lastname@example.org
OR, If you do not have ssh-copy-id (or are an admin injecting this into someone's account as root), you can
- use scp to copy the public key,
- ssh in, and
- (on *nix) append the key to ~remoteuser/.ssh/authorized_keys
The following one-liner has the same effect:
cat ~/.ssh/my_new_identity.pub | \ ssh email@example.com 'cat - >> ~/.ssh/authorized_keys'
Tell your client to use the private key
Varies wit client.
On unices:If you only ever use one key everywhere, you can use it as your default identity by copying it to (for RSA keys) and be done with it (id_dsa for DSA keys). .
When you use more than one, you'll likely want to edit your and add entries like:
Host ssh.example.com IdentityFile ~/.ssh/my_new_identity
Note that having an (applicable) IdentityFile entry overrides the use of your default identity, which is one reason why you'ld probably use Host-specific IdentityFile entries.
In PuTTY you first need to convert the key to a format it understands.
When keypairs don't work, it's not always immediately clear why.
For example, say you've created a passphraseless keypairs, copied it, configured it to be used, yet it asks for a password.
The two main things to do are:
- adding -vv to the client ssh command. The relevant part for me was:
debug1: Next authentication method: publickey debug1: Offering public key: /home/myusername/.ssh/id_dsa debug2: we sent a publickey packet, wait for reply debug1: Authentications that can continue: publickey,gssapi-with-mic,password debug2: we did not send a packet, disable method
Okay, so it's being disqualified.
- Looking at the server side log, which in my case showed:
Authentication refused: bad ownership or modes for directory /home/myusername
In particular, sshd doesn't like group-write permissions on or , so you may want most of:
chmod go-w ~/ chmod 700 ~/.ssh chmod 600 ~/.ssh/* # need not be so blanket-restricted, but it's easier
(you can tell the server not to be pedantic about this, but fixing permissions is the more secure fix)
Types of setup
As described. The default on most systems.
Properties you might care about:
- Doesn't help to deter brute forcing of interactive login
interactive + keypair
- Adds keypair features
- e.g. passphrasekess login for people that use keypairs
- Doesn't deter online brute forcing
- because keys are not required (at least not by default / for all accounts).
- deters online brute forcing
- makes it harder for legitimate users to log in
- they need to have their keypair always
- so usually used only on servers(/accounts) that need to be quite secure
- also not necessarily handy/secure when the systems they typically log in from are multi-user
- note that this is not two-factor auth when people use passphraseless logins
- because they remove the something they know. When the key is stolen, the account is compromised
Since you trust a specific user implicitly, based on their key and nothing else, you're immediately screwed if that key is copied. So never store(/use) passphraseless keys on multi-user systems if you don't fully trust the system's security, or administration.
The extra annoyance of having to have a key is somewhat harder to explain than address whitelisting, which is why IT departments often go for that instead, at least for public system.
Implications, notes and thoughts
The security warnings above are for public, multi-user setups, and cases where logins are regularly administrative
If you are the only one on your server and your workstation, or have similar non-admin accounts in different places with no important documents, having them blindly trust each other can just be pretty darn useful.
The trust will work for one user at a time, because a key will be linked to a user.
I am currently making an account with the same name as my university login so that I can use scp very simply - that is, so that I don't have to specify a user.
You can create mutual trust (e.g. root on one system trusting root on another, but be careful - this means if one system is hacked, they're both hacked.
It is a very bad idea to allow root logins over SSH this way. It is probably a good idea to make an 'incoming' account.
Since all your clients have to store the private key and people may ever get to it, you should probably make a specific keypair for specific purposes instead of using one general identity keypair everywhere.
The "your key is unsafe if you're hacked" argument can be countered with that that's only directly true for escalations up to root. And of course it's only true for the client that has the public key stored; the server only has the public key, which is called that for a reason:)
For the same reasons you should probably not make it passphraseless.
Each connection template can reference to a private key (file). It's under Connection → SSH → Auth.
PuTTY wants key in the format specified by RFC 4716, which one of various formats. If you created the keypair using OpenSSH, you need to convert it. One way of doing so:
- downloading PuTTYgen 
- "load an existing private key". It filters for only for its own .ppk extension, even though it understands others; you need to have it look for *.* instead.
- "save private key". It'll save in the format PuTTY wants.
Remembering keys: agents
SSH agents keep private keys in memory, meaning you can get automatic log in.
If using OpenSSH under a *nix, there is ssh-agent. It works by being the parent of processes that use it so that only the child process can ask for and use the key.
It's fairly common to have it wrapped around interactive shells, so that any aware client (ssh, scp, etc) will notice the environment variables that have been set, and ask ssh-agent for keys when it needs them. You add keys to this agent with ssh-add.
This has a few upsides, like:
- private keys may come from the disk or network, but their passphrase-decoded form is only ever stored in memory, even on flat clients
- gives you a 'remember passphrase for some set time' feature
See ssh-agent man page and such for details.
Pageant is PuTTY/Windows specific. It's similar to ssh-agent, but instead is a background process that stores keys, which PuTTY (Other things as well?(verify)) will notice and use. (What about access control?(verify))
See pageant documentation for details.