From owner-freebsd-security@freebsd.org Mon Aug 22 23:06:47 2016 Return-Path: Delivered-To: freebsd-security@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 32D29BC229F for ; Mon, 22 Aug 2016 23:06:47 +0000 (UTC) (envelope-from vangyzen@FreeBSD.org) Received: from smtp.vangyzen.net (hotblack.vangyzen.net [199.48.133.146]) by mx1.freebsd.org (Postfix) with ESMTP id 1D9C91D27; Mon, 22 Aug 2016 23:06:46 +0000 (UTC) (envelope-from vangyzen@FreeBSD.org) Received: from ford.home.vangyzen.net (unknown [76.164.15.242]) by smtp.vangyzen.net (Postfix) with ESMTPSA id 5407D56488; Mon, 22 Aug 2016 18:06:45 -0500 (CDT) Subject: pam_ssh and default key file names [was: Re: svn commit: r304626 - head/lib/libpam/modules/pam_ssh] To: Bryan Drewery , freebsd-security@FreeBSD.org References: <60cfbe14-5110-df59-29f3-2ede0fcf5456@FreeBSD.org> <26e1bd89-46c4-e1c1-4c2a-5ac9a830f0c7@FreeBSD.org> <6a114818-d4aa-6fd0-1770-22c8d6bed9e0@FreeBSD.org> From: Eric van Gyzen Message-ID: Date: Mon, 22 Aug 2016 18:06:44 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <6a114818-d4aa-6fd0-1770-22c8d6bed9e0@FreeBSD.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2016 23:06:47 -0000 On 08/22/2016 16:11, Bryan Drewery wrote: > On 8/22/2016 1:01 PM, Eric van Gyzen wrote: >> I had never looked at pam_ssh before. Does it really ignore authorized_keys and > > Yeah, that was the entire purpose! > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=15158 Ah, thanks for that research. > For its original purpose I can understand using it, to login *locally*... Yeah, pam_ssh makes sense for local logins, but even then I still find it alarming that it looks at all default key file names. If I change pam_ssh to only use authorized_keys, I would be adding the assumption that users authenticate with the same keys over ssh as on the console. The current pam_ssh code allows different keys (viz. authorized_keys versus id_foo). This seems like a perfectly reasonable assumption. I'd like to hear whether this would break anyone's deployment of pam_ssh. If so, I'd also like to hear a strong argument for such a use case. I might have to ask on, say, questions@ to get a wider audience. > I am surprised to find this too. Thanks for confirming my remaining sanity. :) > At least it is off-by-default: Indeed. > The manpage has this gem: > "nullok Normally, keys with no passphrase are ignored for > authentication purposes. If this option is set, keys with no passphrase > will be taken into consideration, allowing the user to log in with a > blank password." > > Why would anyone ever use nullok and use the pam_ssh module? I don't > know pam well but I'm sure there's another way to make a check always > succeed without a password. So supporting nullok in pam_ssh is just > asking for an unknown security bug. Yes, I also don't like nullok here. There are use cases for a private key without a password, but this is not one of them. > Why is it even in the remote service files as an example when it is > dangerous in those contexts? Good point. I'll remove it from the dangerous examples (unless you beat me to it, since it's time for supper). ;) Eric