Skip site navigation (1)Skip section navigation (2)
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+d2p1-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: <http://docs.FreeBSD.org/cgi/mid.cgi?1449813845.30424.81.camel>