From owner-freebsd-questions@freebsd.org Fri Dec 11 07:27:59 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 115D89D6CC5 for ; Fri, 11 Dec 2015 07:27:59 +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 CFBF519E3; Fri, 11 Dec 2015 07:27:58 +0000 (UTC) (envelope-from terje@elde.net) Received: from [10.130.11.109] (unknown [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 DFDB6B6C; Fri, 11 Dec 2015 07:27: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: <1449813845.30424.81.camel@michaeleichorn.com> Date: Fri, 11 Dec 2015 08:27:45 +0100 Cc: Matthew Seaman , freebsd-questions@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20151203083926.72ad74db.freebsd@edvax.de> <565FFBDF.40907@FreeBSD.org> <1449813845.30424.81.camel@michaeleichorn.com> To: "Michael B. Eichorn" 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 07:27:59 -0000 > On 11 Dec 2015, at 07:04, Michael B. Eichorn wrot= e: >=20 > 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 Terje