LWN: Comments on "SSH: passwords or keys?"

Solution: how to enforce both passwords and keys:

shaiay — Tue, 10 Apr 2012 16:34:41 +0000

No need to decide, a simple solution exists!
In a nuthshell, allow only key based logins, and use the ForceCommand option in sshd_config to force PAM authentication.
The user than has to have a key to login, but after they login, they are forced to authenticate via PAM, regardless of whether their key is password protected!
Full procedure in this blog post

SSH: passwords or keys?

nix — Fri, 22 Jan 2010 15:27:40 +0000

True. Perhaps a better way of saying it is that keys which allow the
carrying out of functions which you do not want a random thief to be able
to carry out, or keys which allow anything (J. Random Normal SSH Identity)
should be passphrased. The rest don't need to be, because nothing bad will
happen if random people get the ability to do whatever that key allows.

(Also, keys stored in a location where the key can't be stolen, e.g. in a
Mars rover, are probably safe nonpassphrased. :) )

SSH: passwords or keys?

nye — Thu, 21 Jan 2010 15:04:37 +0000

>Of course, for use by humans, an agent and a passphrased key is strictly better than a nonpassphrased key.

In general, yes. *Strictly*, no.

Here is an example of when I have used a non-passphrased key. It may seem contrived now, but it was in real use at the time:

Back in ye days of dial-up, I had one machine with a modem in it, connected to the phone line. Dial-on-demand was not an option, as the line was also used for voice, so we needed more control about when to connect, so that left the problem of how to initiate (and terminate) a connection from any other machine. The simplest solution was to use a passphraseless SSH key, permitted to perform both of those tasks and nothing else. None of the users (read: my family) used SSH for anything else, so using an agent would be indistinguishable from not having one.

So, what's the extent of the possible damage?

If somebody had broken into the house and stolen one of the computers with the key on, then they would have gained the ability to connect to the internet the next time they broke in, without having to bring their own modem or subvert the machine plugged in to the phone line. I wouldn't consider that a particularly pressing concern given that *there's somebody in my house dismantling my computers*.

I suppose the most obvious counter-argument is that this is a task which could easily have been done using something other than SSH, but it was still the simplest solution.

SSH: passwords or keys?

nix — Wed, 20 Jan 2010 21:32:10 +0000

Again, it is not always possible to have humans bash things in to all
systems that run unattended and have to connect to other systems. For that
subset, nonpassphrased keys are reasonable. (For the application I'm
thinking of, if they steal the drive we silently fail over, and, ooh, the
attackers would be able to run a backup without our knowledge! How
terrible! Of course, if they've stolen the drive, they're going to be on
the wrong side of a firewall anyway. This isn't *my* private SSH key: this
is a key created specifically to allow a single backup daemon to stream
backups to the backup server. That's all.)

SSH: passwords or keys?

mmcgrath — Wed, 20 Jan 2010 20:03:29 +0000

Sorry but I don't lax my security for bots that run commands unattended. If you're running raid1 and someone comes and takes a drive. You can pretend all you want that your private ssh key is safe. Me? I know it is.

SSH: passwords or keys?

nix — Wed, 20 Jan 2010 19:59:16 +0000

Of course, for use by humans, an agent and a passphrased key is strictly
better than a nonpassphrased key. (But that wasn't the case you were
discussing.)

SSH: passwords or keys?

hppnq — Wed, 20 Jan 2010 09:40:19 +0000

Sorry if it was not clear, but the whole point of my comment was of course that logging in to type a passphrase is not an option, for several given reasons. I wanted to point out that -- contrary to what you suggested -- running ssh-agents is not making things more secure by default. Especially if you worry -- as you seem to be doing -- about the kind of incidents that involve unauthorized access to systems and disks.

SSH: passwords or keys?

mmcgrath — Tue, 19 Jan 2010 14:40:31 +0000

Just as a side note to this, are you also not using encrypted filesystems at any of your remote locations?

SSH: passwords or keys?

mmcgrath — Tue, 19 Jan 2010 14:05:36 +0000

> In the real world (a datacenter, for instance) systems can't be rebooted because of ssh-agent, with obvious security and maintenance consequences. There has to be a procedure that contains the passphrase in clear text, for obvious reasons.

All of my servers are in a data center. When they reboot, I (or another admin) log in and start the agent. Surely you thought this through and realized that?

SSH: passwords or keys?

nix — Tue, 19 Jan 2010 09:36:20 +0000

If the machine is automatically rebooted and unattended (as is true of a
lot of unattended systems with panic_on_oops and reboot-on-panic set), you
really can't rely on having a human present to manually type in a
passphrase when the system boots. The sorts of keys I'm thinking of aren't
superprivileged anyway: this isn't 'ssh to root' but 'ssh to my
counterpart on some other system to exchange data' or 'ssh to the backup
server using an ssh subsystem designed for one-way backup transfer' (i.e.
you can't use it to *steal* backups). (And yes, I do both routinely.)

SSH: passwords or keys?

hppnq — Tue, 19 Jan 2010 07:19:52 +0000

In the real world (a datacenter, for instance) systems can't be rebooted because of ssh-agent, with obvious security and maintenance consequences. There has to be a procedure that contains the passphrase in clear text, for obvious reasons.

Even if there is time and money and you have stored your passphrase in the Pentagon vault, the security problem is not solved by simply rebooting and typing in the passphrase. There is the risk of someone sniffing the passphrase or being able to hijack the session or otherwise fool ssh-agent.

Your example is a rather contrived one in that it highlights only a small part of the problem and solution space. The problem of protecting a running ssh-agent is remarkably similar to protecting an unencrypted key. And I would definitely worry if someone got their hands on my encrypted key also, by the way.

SSH: passwords or keys?

mmcgrath — Mon, 18 Jan 2010 23:57:34 +0000

> Obviously I'm missing something.

heh, the thing you're now missing is an unencrypted ssh key. Be it stolen, copied, or just not disposed of properly (like the case of an old drive). An unencrypted ssh key is much more useful for causing damage then an encrypted one. So what if you have to unlock it on reboot.

SSH: passwords or keys?

nix — Mon, 18 Jan 2010 23:23:15 +0000

I don't see the connection between your first sentence and your next two.
Obviously I'm missing something.

SSH: passwords or keys?

mmcgrath — Mon, 18 Jan 2010 22:07:51 +0000

> It can hardly use an agent: there's no user there
upon reboot to type in the passphrase.

I use an agent. Ever had to get a drive replaced? Ever had your boss ask you what was on that drive?

SSH: passwords or keys?

nix — Mon, 18 Jan 2010 22:04:41 +0000

How's a daemon on an unattended box going to ssh around the place without
a passphraseless key? It can hardly use an agent: there's no user there
upon reboot to type in the passphrase.

SSH: passwords or keys?

mmcgrath — Mon, 18 Jan 2010 19:40:24 +0000

> Passphraseless keys have their uses

No they don't, but ssh-agent does.

SSH: passwords or keys?

jschrod — Mon, 18 Jan 2010 14:42:21 +0000

Well, I suppose the option may be for paranoid people who don't want to use their agent-stored identities for authentication tries against unknown ssh servers. Me, I use it mainly for debugging connection and/or authentication problems to well-known servers when the ssh daemon there is running in debug mode and I want to have precise control what my client sends to it.

SSH: passwords or keys?

nix — Sun, 17 Jan 2010 22:59:59 +0000

Well, yes. I administer system A and system B in this scenario, and I
trust myself (but not system C, and agent forwarding is turned off for the
ssh to system C: but it insists on using the agent's keys anyway, even
though I specifically asked it to use a different one using -i.)

SSH: passwords or keys?

gmaxwell — Sun, 17 Jan 2010 19:43:41 +0000

Proper key strengthening makes off-line brute force attacks annoyingly difficult against all except the weakest keys. There is pretty much no way to eliminate an off-line brute force attack: Even if you instead require passwords that attacker could capture the exchange with the server and execute a brute force attack against the session crypto.

SSH: passwords or keys?

janfrode — Sun, 17 Jan 2010 18:08:50 +0000

Then I hope you have complete trust in the admins and security of those boxes, as they can easily use your private keys (unless you have the agent prompt you to confirm every auth).

SSH: passwords or keys?

nix — Sun, 17 Jan 2010 13:34:45 +0000

Sorry, I missed a bit. System B can talk to system A's agent because agent
forwarding was turned on (I tend to have it on almost everywhere because
normally it's useful).

SSH: passwords or keys?

marcH — Sat, 16 Jan 2010 15:20:36 +0000

I am afraid I am lost here... how can system B talk to the agent running on system A!?

My experience with ssh-agent and multiple identities is quite different. The agent never "insists" but quickly gives up and eventually lets ssh use the "-i" key.

SSH: passwords or keys?

nix — Sat, 16 Jan 2010 12:32:00 +0000

System A had an agent running on it. I sshed to system B, which has a pile
of identities on it, and tried to use one of them to get to system C. No
can do, it insisted on using system A's key, which system C had never
heard of.

SSH: passwords or keys?

nix — Sat, 16 Jan 2010 12:29:37 +0000

OOo. Thank you, that's very useful! (though I'm not sure it'll help if you
have lots of identities in your .ssh directory which the agent doesn't
know about. I suppose the solution there is to add them to the agent.)

SSH: passwords or keys?

dtlin — Fri, 15 Jan 2010 15:57:56 +0000

Sshpass is a tool for non-interactivly performing password authentication with SSH's so called "interactive keyboard password authentication".

... yeah.

SSH: passwords or keys?

paulj — Fri, 15 Jan 2010 12:27:13 +0000

It's not random, it's documented in the kinit manual page.

You need an environment variable really, otherwise every krb5-or-GSS using
client you run needs to have an explicit option (argument, conf file, and/or in the
UI) to specify the ticket cache.

It's not as transparent as using having SSH keys though, unfortunately.

SSH: passwords or keys?

marcH — Fri, 15 Jan 2010 09:58:28 +0000

How could you notice this? (besides enabling verbose mode)

SSH: passwords or keys?

jschrod — Fri, 15 Jan 2010 02:28:52 +0000

You have to add -o IdentitiesOnly=yes to skip the agent's keys.

SSH: passwords or keys?

foom — Thu, 14 Jan 2010 22:53:24 +0000

> The former is really easy. The user can authenticate with multiple kerberos
> realms quite easily, just by specifying different ticket caches when using kinit
> (I open a new session and set KRB5CCNAME).

You call that *easy*??

However, IIRC from last I used kerberos, you can actually kinit to multiple realms just fine without
setting random environment variables.

SSH: passwords or keys?

mmcgrath — Thu, 14 Jan 2010 22:26:34 +0000

> a) 1 user accessing services authenticated via 2 separate Kerberos systems?

Yeah I mean that. We have kerberos at $DAYJOB. The real concern isn't so much that someone technical (myself) could get it working. But more to make sure that people less technical (say, an art designer in their first year of college) could access both locations without confusion.

Some contributors get confused just generating ssh key pairs.

SSH: passwords or keys?

nix — Thu, 14 Jan 2010 22:25:11 +0000

ssh-agent has one problem: it breaks use of multiple keys. If you have an
agent running, the agent is *always* used, even if you specified a
different key via ssh -i. Very annoying (but I still use ssh-agent
everywhere).

SSH: passwords or keys?

paulj — Thu, 14 Jan 2010 22:15:47 +0000

Hi,

Do you mean:

a) 1 user accessing services authenticated via 2 separate Kerberos systems?

b) Kerberos systems co-operating, such that 1 system will accept user
credentials issued by the other?

The former is really easy. The user can authenticate with multiple kerberos
realms quite easily, just by specifying different ticket caches when using kinit
(I open a new session and set KRB5CCNAME).

The latter is cross-realm authentication and requires joint-administrative
fiddling to setup.

I think you mean the former, which is not a problem at all.

SSH: passwords or keys?

Comet — Thu, 14 Jan 2010 21:41:24 +0000

Passphraseless keys have their uses, provided that they're used for role-
specific work and are heavily locked down on the server. I've used such
keys with hosts="...",command="...",no-foo restrictions and it's a much
better option than the alternatives -- if you use a custom daemon, you have
to worry about buffer overflows pre-authentication, whereas ssh-based
automation lets you ensure authentication over an established protocol
before getting into the custom code for handling some specific task.

At $previous_employment, we had bastion hosts for remote access based on
two-factor auth, and then SSH from those hosts to further in. I ran an
audit for passphraseless keys there, found some, and others with passwords
so simple that a naive brute-force unlock, written in shell, could find
them. Those got reported to the managers of the staff involved, who could
deal with the people problems, and we then just ran the new audit
routinely.

So, two-factor auth to get in, SSH with passphrases and education about
using ssh-agent to move about. Worked well enough.

SSH: passwords or keys?

tseaver — Thu, 14 Jan 2010 20:43:26 +0000

I agree that neglecting to mention ssh[-agent was a puzzling oversight. I've been using it successfully for ten years now (it has gotten easier since gdm started helping instead of getting in the way), and therefore have a *terrifically* long / high-entropy passphrase on the key, which I type once per login to the box where the private key is stored.

I never reuse my private key across machines, and never allow root login or password-based login over SSH on any host I admin. I like this setup a lot, and can't imagine that anybody thinks password-based schemes are intrinsically "more secure."

SSH: passwords or keys?

quotemstr — Thu, 14 Jan 2010 20:07:52 +0000

ensure that people could not use password-less keys, and the only way to do that was to ban the use of keys altogether.

There's still expect.

SSH: passwords or keys?

kamil — Thu, 14 Jan 2010 19:26:24 +0000

Not exactly what you asked for, but it is possible to restrict access to a list of hostnames/ip addresses using the "from" option in authorized_keys; see sshd(8).

SSH: passwords or keys?

kamil — Thu, 14 Jan 2010 19:19:15 +0000

At my previous job, the systems group set up SSH on the servers such that it would not accept the keys -- you had to use the passwords. As a user I found it rather annoying, but the motivation was not completely without merit -- they wanted to ensure that people could not use password-less keys, and the only way to do that was to ban the use of keys altogether.

Need I mention that the systems group there was a real BOFH club? :-)

SSH: passwords or keys?

drag — Thu, 14 Jan 2010 18:08:31 +0000

I've never done multiple domains on a kerberos system, but it should not be terribly difficult as long as the users are comfortable using the kerberos tools. You just can't use to as part of the automated login process. There is nothing stopping you after you login to add more credentials manually though using the command line.

2) If someone has my password and ssh key, doesn't kerberos not do anything to protect at that point? That's why we're thinking hardware key, but some of our admins are very opposed to it.

Yes. Your screwed. But if you think about it the only way that happens normally is if the attacker has violated your user's desktop, right? So your going to be screwed pretty much no matter what. If the machine your coming in on is rooted then your f-ed pretty much no matter what.

The weakest link is always going to be the user's password. You can make the system and the desktop as secure as possible, but the number one security problem nowadays stem generally from users.

If your worried about weak passwords then use PAM in combination with a one-time pad/password. The pad can be generated by hardware, which is probably the thing your looking at, or manually entered in combination with a java applet on a phone or key dongle or something like that. That way you get your 2-factor authentication.. the password generated by the user and the password generated by one-time-pad-thingy. There are a few projects like that.

But that is a pretty easy way to piss off your end users. Being fairly nazi about password policies, implementing kerberos, and disabling shared key support is probably the best/safest bet for a organization. There is not really much you can do to get around this human-based weakest link.

For a small number of machines and if you got a small group (say 3-4, probably less then 10) then ssh keys make sense.

Also there are other things you can do. For example on my machines for a while I stored a 'key' on a USB drive and used that. There are PAM modules that will look for that key and allow me to log in or not in addition to me having the correct password, but that requires physical access to the machine, so it is very hateful.

If anything other then keys are just unacceptable then there are third party patches to that will actually add PKI support to OpenSSH, but there is good reasons why the OpenBSD folks are refusing to accept them into the normal OpenSSH source code distribution. I'd probably take some time to understand those reasons before deploying a PKI OpenSSH solution.

All of this is just my opinion, of course. And only really is relevant in the broad sense, even if I am not wrong. Don't take it as gospel no matter what you do!! Each Org is different with different requirements and different needs!

SSH: passwords or keys?

mmcgrath — Thu, 14 Jan 2010 17:25:53 +0000

So my kerberos knowledge is admittedly limited but we've had that talk a couple of times as well. Here's the concerns (the first is kind of unique)

1) No one works with the Fedora Project as their only job. Which means it's likely some people will have to register with two kerberos environments in order to do their day job and work on Fedora. My understanding is that's fairly complex and not all of our contributors are very technical.

2) If someone has my password and ssh key, doesn't kerberos not do anything to protect at that point? That's why we're thinking hardware key, but some of our admins are very opposed to it.

/me invites anyone interested to join the fedora-infrastructure-list and discuss this. It's a topic we take pretty seriously.

SSH: passwords or keys?

drag — Thu, 14 Jan 2010 17:17:35 +0000

To me keys are just bad news all around for any organization.

Kerberos all the way. That is really the only way to do it and it's sad
that it's still a PITA to get something that should be dead simple
nowadays.

There is a reason why the OpenSSH folks refuse to implement PKI, which is
really what you want to do if your into key management. There are just lots
of problems to a approach like that. Kerberos is just much better.

If you want to do things securely without kerberos then a option is to do a
combination of passwords with a one time password. There are numerous
little doo-dads you can do that as well as programs you can install on a
cell phone or other java-enabled device.

Now it sucks because a lot of people use ssh keys for automation. I think
that there has to be a better way.