SSH - keypair logins
| Security related stuff.
Securing services
Unsorted - · Anonymization notes · website security notes · integrated security hardware · Glossary · unsorted |
What a keypair is
- a public key
- a private key
The two belong together in a mathematically entangled way, which only works that way because they are generated together.
A keypair is in itself just two chunks of data, and it does not yet have any meaning, or relation to a person, account, host, nor does it relate to any specific permissions, until you tie it to one.
Once you do, we conveniently think of it as that role acting in a way that only they can.
We use keypairs like this in part because unlike passwords, you can't easily change it to a weak one.
There are a number of different uses for keypairs ,
and many are not specific to SSH, but instead of getting into wider theory...
...what keypairs usually do for SSH is to have one host account trust a specific key, account, and/or identity.
- Really just trusts the key, and whoever has that key can do the trusted thing
The reason you'ld do this "specific account trusts specific other account" is that it is an easy way to think about managing such trust relations.
Because in practice
- we give to to a person and tell them to not reveal it
- they probably put it in a specific account (at what you'd call the client side)
- the thing you'd call the server side would assume use of that key is that account / person / sometimes group
Note that this trust is
- ...in one direction, and
- ...only secure as long as the private key of the pair is kept secret.
And given how easy it is to create a keypair, having each role (even each direction) have a unique, distinct purpose helps you keep track of things,
and may also let you revoke just one role at a time.
Try to name them clearly, if you want that ease/ability to stick around.
when we like keypairs
Can hinder brute forcing
You can require that an account login always supply a key.
If you do, then 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.
(or sometimes username+key, if you use an empty passphrase. Not recommended unless you can explain that that isn't a bad idea, considering this is one-factor auth again, and with a secret that may easily end up stored on a shared server.)
This is the kind of 2FA where a remote user cannot do anything when they don't have their key with them.
Which is secure against unknown people, but also annoying for known users.
And a reason this variant is usually only done on more critical systems.
To people with SSH servers: 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, but still, peace of mind is nice.) A specific user configuring this means they doesn't have to worry about the fact that port 22 is open to the entire internet.
There are other alleviations to that, and it's recommended you look at them, but they each have their own limitations.
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 without having to type in anything.
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, and the cluster is probably firewalled from everything else
- 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
- convenience.
- 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.
sharing accounts
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.
How to set up account-to-account trust
Create a keypair
cd ~/.ssh # not necessary, but it's a decent place to keep them
ssh-keygen -f my_new_identity # there are type and length details you sometimes care about
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
Make a remote account trust the public key
If you have ssh-copy-id:
ssh-copy-id -i my_new_identity.pub remoteuser@ssh.example.com
If you do not have ssh-copy-id, the following one-liner has the same effect:
cat ~/.ssh/my_new_identity.pub | \
ssh remoteuser@ssh.example.com 'cat - >> ~/.ssh/authorized_keys'
If you like to do that manually to avoid a typo doing weird things, or are an admin injecting this into someone's account as root):
- copying the public key (a text file)
- ssh in so that you can...
- append the key to ~remoteuser/.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 ~/.ssh/id_rsa (for RSA keys) and be done with it (id_dsa for DSA keys).
When you use more than one, you'll likely want to use a key it only on the host(s) you need it.
Edit your ~/.ssh/config and add entries like:
Host ssh.example.com IdentityFile ~/.ssh/my_new_identity
Note that having an applicable IdentityFile entry overrides the use of a 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.
Problems
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 ~/.ssh 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
interactive only
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).
keypair only
- 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.
PuTTY
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 [1]
- "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.