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
Those two belong together, not because someone says so, but in a mathematically entangled way, generated together.
And just that, two chunks of data.
It does not yet have any practical meaning yet -- maybe it's used for message signing, or maybe for encryption.
It has no relation to a person, account, host, or ability to do a specific thing, and only gets such meaning only once you start using it for something.
...but often it's about trust.
One common thing to do is give one computer the private key and make it encrypt data with it, and another computer the public key so that it can verify only the computer with the private key could have generated that data. Now we have communication that only we can see, and we can know comes from a specific source.
It is practically convenient to start thinking of a particular keypair as representing the role/ability you have started using it for.
It is also common for that use to be 'make this computer trust connections from that computer', which we often tie to specific user accounts, so we talk as if people (or functional accounts) are the ones being trusted.
Why we use keypairs instead of something else is a separate discussion, but e.g. contrasted with passwords, it's harder to accidentally share, and harder to change to a weaker one. Yet there is a lot more to it than that, and you absolutely can do dumbly insecure things with them.
Let's narrow that to what keypairs do specifically within SSH: adding a specific trust relation.
More technically, you give it a specific public key, and it can check that data you give it later could only have been generated by someone with the according private key.
And while at a low level it cares only about that key.
So more practically, 'this specific account now recognizes use by someone with this key'.
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,
- everyone now has to log in with username+key+passphrase.
This is one of various forms of two-factor authentication: something you have (the key), and something you know (the passphrase that lets you access it).
The upside is that a script kiddie doing dumb attacks (connect to thousands of internet hosts and try user database password 123456) will now fail even if that is correct. It is only once you specifically become interesting enough to find your key that it gets as risky as before -- but that is a higher threshold.
One downside is that known users can only do anything when they have their key with them. And they need to carry and use it safely, or risk losing it.
And a reason this variant is usually only done on more important systems.
convenient passwordless login
Note that the passphrase is not entangled with the keys themselves. You can consider the passphrase as access to the private key - which happens to be best solved via encryption. Such encryption keys happens to be a regular but optional part of storing private keys on disk
However, because passphrases are allowed to be short, a passphrase should not be considered the thing that makes your private key safe, because brute forcing will reveal that key from an encrypted file if your passphrase is bad enough.
Also, passphrases are allowed to be empty, or not used at all:
A variant of 'proper' keypair login is to require a key,
but use no passphrase / an empty passphrase.
This is not recommended unless you can explain that that isn't a bad idea.
It's basically one-factor again: access with something you have, without something you know.
Yes, something you have might be a little harder to steal, and it
and still decent against aforementioned script kiddies.
But once you become interesting enough to target, you are an easier target than if you had a password as well. If they find your key, they now have access without even having to type anything.
So while this may be good against non-targeted attacks,
is does not stand up well when you are a person of interest to anyone.
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
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.