From owner-freebsd-questions@freebsd.org Fri Dec 11 06:04:10 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 230589D77A7 for ; Fri, 11 Dec 2015 06:04:10 +0000 (UTC) (envelope-from ike@michaeleichorn.com) Received: from mx1.eichornenterprises.com (mx1.eichornenterprises.com [104.236.13.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.eichornenterprises.com", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C8BA4195C; Fri, 11 Dec 2015 06:04:09 +0000 (UTC) (envelope-from ike@michaeleichorn.com) Received: from mail.eichornenterprises.com (cpe-184-59-147-149.neo.res.rr.com [184.59.147.149]) by mx1.eichornenterprises.com (OpenSMTPD) with ESMTP id eddc62e6; Fri, 11 Dec 2015 01:04:05 -0500 (EST) Received: by mail.eichornenterprises.com (OpenSMTPD) with ESMTPSA id 2ac19b35 TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO; Fri, 11 Dec 2015 01:04:04 -0500 (EST) Message-ID: <1449813845.30424.81.camel@michaeleichorn.com> Subject: Re: best practice for locking down private jail? From: "Michael B. Eichorn" To: Terje Elde , Matthew Seaman Cc: freebsd-questions@freebsd.org Date: Fri, 11 Dec 2015 01:04:05 -0500 In-Reply-To: References: <20151203083926.72ad74db.freebsd@edvax.de> <565FFBDF.40907@FreeBSD.org> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.18.2 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit 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: Fri, 11 Dec 2015 06:04:10 -0000 On Thu, 2015-12-10 at 20:55 +0100, Terje Elde wrote: > > On 03 Dec 2015, at 09:22, Matthew Seaman > > 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.