SSH - keypair logins

From Helpful
Jump to navigation Jump to search
Security related stuff.


Linux - PAM notes · SELinux

Securing services


A little more practical


More techincal waffling

Message signing notes · Hashing notes ·
Auth - identity and auth notes
Encryption - Encryption notes · public key encryption notes · data-at-rest encryption ·pre-boot authentication · encrypted connections

Unsorted - · Anonymization notes · website security notes · integrated security hardware · Glossary · unsorted

This article/section is a stub — probably a pile of half-sorted notes and is probably a first version, is not well-checked, so may have incorrect bits. (Feel free to ignore, or tell me)


What a keypair is

At the lowest level, a keypair refers to to pieces of data:

  • a public key
  • a private key

The two are generated together, and belong together in a (mathematically) entangled way.



There are a number of different uses for keypairs , and they are certainly not specific to SSH, but instead of getting into wider theory...


What it is typically used for around SSH is to have one host account trust a specific key, account, and/or identity

which of those apply depends on how exactly you use it; strictly speaking it trusts they key, but
practically you usually tie it to an account
practically you often think of that account as relating to a specific person (or sometimes group)
mostly for the practical reason that "specific account trusts specific other account" is an easy way for us to think about managing such trust relations

To reiterate: a keypair is in themselves, just two chunks of data, and it does not relate to a person, account, host, use, or anything else, until you make tie it to one. From that point on, we conveniently think of it as that role acting in a way that only they can.


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.

See e.g. http://stackoverflow.com/questions/2224066/how-to-convert-ssh-keypairs-generated-using-puttygenwindows-into-key-pairs-use

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

This article/section is a stub — probably a pile of half-sorted notes and is probably a first version, is not well-checked, so may have incorrect bits. (Feel free to ignore, or tell me)

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.

See also