Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 22 Aug 2016 18:06:44 -0500
From:      Eric van Gyzen <vangyzen@FreeBSD.org>
To:        Bryan Drewery <bdrewery@FreeBSD.org>, freebsd-security@FreeBSD.org
Subject:   pam_ssh and default key file names [was: Re: svn commit: r304626 - head/lib/libpam/modules/pam_ssh]
Message-ID:  <dcc8cf68-82ea-dcf1-31c3-d9d8886748d0@FreeBSD.org>
In-Reply-To: <6a114818-d4aa-6fd0-1770-22c8d6bed9e0@FreeBSD.org>
References:  <60cfbe14-5110-df59-29f3-2ede0fcf5456@FreeBSD.org> <26e1bd89-46c4-e1c1-4c2a-5ac9a830f0c7@FreeBSD.org> <6a114818-d4aa-6fd0-1770-22c8d6bed9e0@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?dcc8cf68-82ea-dcf1-31c3-d9d8886748d0>