From owner-freebsd-questions@freebsd.org Thu Dec 10 19:55:58 2015 Return-Path: Delivered-To: freebsd-questions@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5001A9D6343 for ; Thu, 10 Dec 2015 19:55:58 +0000 (UTC) (envelope-from terje@elde.net) Received: from rand.keepquiet.net (keepquiet.net [144.76.43.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "keepquiet.net", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 155BA1D70; Thu, 10 Dec 2015 19:55:57 +0000 (UTC) (envelope-from terje@elde.net) Received: from [10.130.11.109] (cm-84.210.87.28.getinternet.no [84.210.87.28]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: terje@elde.net) by rand.keepquiet.net (Postfix) with ESMTPSA id 87FFAB25; Thu, 10 Dec 2015 19:55:54 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: best practice for locking down private jail? From: Terje Elde X-Mailer: iPhone Mail (13C75) In-Reply-To: <565FFBDF.40907@FreeBSD.org> Date: Thu, 10 Dec 2015 20:55:52 +0100 Cc: freebsd-questions@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20151203083926.72ad74db.freebsd@edvax.de> <565FFBDF.40907@FreeBSD.org> To: Matthew Seaman X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2015 19:55:58 -0000 > On 03 Dec 2015, at 09:22, Matthew Seaman wrote: >=20 > Keys *and* a password doesn't offer any additional security over just > keys alone. Actually, that's not true.=20 It's a fairly common thought, since both are key+password, but there's a ver= y real difference; online vs. offline.=20 If you have an encrypted ssh private key, you can try to brute-force the pas= sword as much as you'd like, in the comfort of your own home.=20 The password on the server though, would have to be tried against the server= , leaving logs, possibly getting your IP firewalled, and alerting admin.=20 This is also where it gets interesting; if you check key before password, so= meone uses the key but fails at the password a mere 3 times, you could revok= e the key, and lock up the user.=20 That's what I'd call a pretty significant boost in security.=20 (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 w= hile in use (as opposed to say, theft, DHS etc), there's a good chance the a= ttacker could keylog the passphrase, at which point most of this would be mo= ot.=20 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 wi= th keys, or take another step up and look at 2FA, or moving SSH keys to hard= ware (smartcard, yubikey...) I'm not suggesting everyone run out and set passwords, not adopt anything I m= ention here, my point is just that there's a difference between encrypted ke= y and key+password, and the difference can be leveraged for gain where appro= priate.=20 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 mac= hines, if key works but password fails on ANY, if key is successfully used f= rom 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.=20 Terje