best practice for locking down private jail?

[Terje Elde]

> On 03 Dec 2015, at 09:22, Matthew Seaman <matthew at FreeBSD.org> wrote:
> 
> Keys *and* a password doesn't offer any additional security over just
> keys alone.

Actually, that's not true. 

It's a fairly common thought, since both are key+password, but there's a very real difference; online vs. offline. 

If you have an encrypted ssh private key, you can try to brute-force the password as much as you'd like, in the comfort of your own home. 

The password on the server though, would have to be tried against the server, leaving logs, possibly getting your IP firewalled, and alerting admin. 

This is also where it gets interesting; if you check key before password, someone uses the key but fails at the password a mere 3 times, you could revoke the key, and lock up the user. 

That's what I'd call a pretty significant boost in security. 

(Granted, the last part of that would perhaps require some scripting)

And your point isn't completely without merit. For a lot of cases it doesn't matter; if the key is compromised because someone got access to the system while in use (as opposed to say, theft, DHS etc), there's a good chance the attacker could keylog the passphrase, at which point most of this would be moot. 

To sum up; for some attackers/scenarios, it can boost security significantly, for others it hardly matters. For most, it's probably better to just go with keys, or take another step up and look at 2FA, or moving SSH keys to hardware (smartcard, yubikey...)

I'm not suggesting everyone run out and set passwords, not adopt anything I mention here, my point is just that there's a difference between encrypted key and key+password, and the difference can be leveraged for gain where appropriate. 


Oh, and final note; there's some possible fun to be had here if anyone is in a scripting mood, such as setting up a system to revoke SSH-keys to ALL machines, if key works but password fails on ANY, if key is successfully used from a non-whitelisted IP, and so on. Later SSHs have some CA-infrastructure, ink. ability to distribute revocation-lists. That opens up to being able to keep revocation ready at hand, and distributing only after its needed. 

Terje