Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 11 Dec 2015 08:27:45 +0100
From:      Terje Elde <>
To:        "Michael B. Eichorn" <>
Cc:        Matthew Seaman <>,
Subject:   Re: best practice for locking down private jail?
Message-ID:  <>
In-Reply-To: <>
References:  <> <> <> <> <> <>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help

> On 11 Dec 2015, at 07:04, Michael B. Eichorn <> wrot=
> 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 b=
reak keys, and that's a very different situation.=20

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

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

> 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 t=
hat is depends a lot on the situation.=20

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

While on the topic of ssh, there's an argument to be made for being careful w=
ith 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 i=
n a key of his own.=20

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

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


Want to link to this message? Use this URL: <>