SSH - keypair logins

From Helpful
(Redirected from SSH keypair logins)
Jump to: navigation, search
Security related stuff.


Theory / unsorted

how to do a login system badly
how to do encryption badly
Disk and file encryption notes
This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)

What a keypair is

A keypair refers to a public and a private key that belong together (were generated together).

Applied practically arond SSH, we can use it to have one host account trust another host account - usually one on a remote host. 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 someone who knows the according private key. (It also matters that private keys cannot be inferred from the public one, or from encrypted communication.)

That "can only have come from a specific thing" is also (ab)usable to verify an already-known identity, which is basically what we're doing 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, and from then it probably has only that meaning.

Yet you can generate any amount. And this has value: you can make them specific-purpose, and so individually retractable.

when we like keypairs

Can hinder brute forcing

You can require that 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's user (you) 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, but still, peace of mind is nice.)

It does mean a user cannot do anything when they don't have their key with them.

Which is secure, but also annoying. And a reason this is usually only done on more critical systems.

(As to those many attempts: On everyday hosts 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 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, 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:
  • the private key: my_new_identity

(You may wish an RSA key
-t rsa
over the default DSA key. Reasons are nontrivial; security against specific cryptanalysis (in which case you may also want
-b 4096
) is only one, things read things like this)

Make a (remote) account trust the public key

If you have
ssh-copy-id  -i

If you do not have ssh-copy-id, the following one-liner has the same effect:

cat ~/.ssh/ | \
 ssh '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
(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
and add entries like:
   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.


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
, 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, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, 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.


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