Date: Fri, 11 Dec 2015 01:04:05 -0500 From: "Michael B. Eichorn" <ike@michaeleichorn.com> To: Terje Elde <terje@elde.net>, Matthew Seaman <matthew@FreeBSD.org> Cc: freebsd-questions@freebsd.org Subject: Re: best practice for locking down private jail? Message-ID: <1449813845.30424.81.camel@michaeleichorn.com> In-Reply-To: <B47F1A5D-AD1D-4A4C-AF63-5CF1C896E0A7@elde.net> References: <CACcSE1yQO8AjW9rpY%2Bd2p1-ArPbO4qKV0zcaCMyRhYEWLOpQGA@mail.gmail.com> <CACcSE1yqeXqd=mLJ-=aJGr0hXcUEE0v3MeiAty6e4cgpWF7D8g@mail.gmail.com> <20151203083926.72ad74db.freebsd@edvax.de> <565FFBDF.40907@FreeBSD.org> <B47F1A5D-AD1D-4A4C-AF63-5CF1C896E0A7@elde.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 2015-12-10 at 20:55 +0100, Terje Elde wrote: > > On 03 Dec 2015, at 09:22, Matthew Seaman <matthew@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 +1 I mostly concur. I like the point about alterting alot. I don't think that the keys are so weak that offline cracking is really that worrysome though. The key encryption method (AES-128-CBC) is beyond the abilties of non-nationstates to attack, and even then it is still deemed very unlikely. Oh and if you are really concerned about password replays, there is opie. Or even key + password + opie + 2FA, or even key + 1 of the others. SSH is fancy! I think most of the talk about key + password has been from the perspective of if a sysadmin needs to do both. If you can trust yourself to protect your keys you probably don't need to add password. But for the less-security minded users both is better, if only because it is hard to enforce encrypted keys.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1449813845.30424.81.camel>