best practice for locking down private jail?

[Terje Elde]

> On 11 Dec 2015, at 07:04, Michael B. Eichorn <ike at michaeleichorn.com> wrote:
> 
> 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.

True for the encryption algorithm, but people don't break algorithms, they break keys, and that's a very different situation. 

Say for example that your password is "f", the attacker tries to guess it starting from "a" and moving on from there. With offline checking, he'd have your password in no time. With online checking - and a limit of three attempts - he'd actually fail completely, despite the horribly bad password. 

> 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!

There's also a patch for OpenSSH to support FIDO U2F floating around. 

> 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.

Yeah, there's definitively a need for finding the right tradeoff, and what that is depends a lot on the situation. 

There's probably also little point in going entirely overboard; if your machine is completely compromised, an attacker would gain access to your logged in sessions, no matter how well you authenticate the session setup. 


While on the topic of ssh, there's an argument to be made for being careful with users ~/.ssh/authorized_keys. If an attacker gains temporary access to a system, it's often too easy to turn that into permanent access by slipping in a key of his own. 

There's a lot of ways to protect against that, such as having sshd look for keys only in a place the users can't write, or running nightly checks and mailing users about changes. 

(First has issue with users loosing access to revoke keys, second has a delay and only gives notification, not prevention). 

Terje