Re: svn commit: r304626 - head/lib/libpam/modules/pam_ssh

[Eric van Gyzen]

I had never looked at pam_ssh before. Does it really ignore authorized_keys and
allow authentication using any of the default key file names? After a quick
read of the code, that certainly seems to be the case. Does anyone else find
that alarming? Sure, it's in my ~/.ssh directory and has appropriate
permissions, but that doesn't mean I want to use it for authentication to this
machine (or any machine sharing this home directory). That's what
authorized_keys is for. I might have created it only to authenticate from this
machine to another one. I might have even given it an empty passphrase because
that other machine is disposable and I don't really care about it.

Eric

On 08/22/2016 14:27, Ollivier Robert wrote:
> Author: roberto
> Date: Mon Aug 22 19:27:20 2016
> New Revision: 304626
> URL: https://svnweb.freebsd.org/changeset/base/304626
>
> Log:
> Add support for Ed25519 keys.
>
> Reported by: mwlucas
> MFH: 2 weeks
>
> Modified:
> head/lib/libpam/modules/pam_ssh/pam_ssh.8
> head/lib/libpam/modules/pam_ssh/pam_ssh.c
>
> Modified: head/lib/libpam/modules/pam_ssh/pam_ssh.8
> ==============================================================================
> --- head/lib/libpam/modules/pam_ssh/pam_ssh.8 Mon Aug 22 19:05:11 2016 (r304625)
> +++ head/lib/libpam/modules/pam_ssh/pam_ssh.8 Mon Aug 22 19:27:20 2016 (r304626)
> @@ -137,6 +137,8 @@ SSH2 RSA key
> SSH2 DSA key
> .It Pa $HOME/.ssh/id_ecdsa
> SSH2 ECDSA key
> +.It Pa $HOME/.ssh/id_ed25519
> +SSH2 Ed25519 key
> .El
> .Sh SEE ALSO
> .Xr ssh-agent 1 ,
>
> Modified: head/lib/libpam/modules/pam_ssh/pam_ssh.c
> ==============================================================================
> --- head/lib/libpam/modules/pam_ssh/pam_ssh.c Mon Aug 22 19:05:11 2016 (r304625)
> +++ head/lib/libpam/modules/pam_ssh/pam_ssh.c Mon Aug 22 19:27:20 2016 (r304626)
> @@ -81,6 +81,7 @@ static const char *pam_ssh_keyfiles[] =
> ".ssh/id_rsa", /* SSH2 RSA key */
> ".ssh/id_dsa", /* SSH2 DSA key */
> ".ssh/id_ecdsa", /* SSH2 ECDSA key */
> + ".ssh/id_ed25519", /* SSH2 Ed25519 key */
> NULL
> };
>
>
_______________________________________________
freebsd-...@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-securi...@freebsd.org"

[Bryan Drewery]

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

For its original purpose I can understand using it, to login *locally*...

I am surprised to find this too.

> allow authentication using any of the default key file names? After a quick
> read of the code, that certainly seems to be the case. Does anyone else find
> that alarming? Sure, it's in my ~/.ssh directory and has appropriate
> permissions, but that doesn't mean I want to use it for authentication to this
> machine (or any machine sharing this home directory). That's what
> authorized_keys is for. I might have created it only to authenticate from this
> machine to another one. I might have even given it an empty passphrase because
> that other machine is disposable and I don't really care about it.

At least it is off-by-default:

> # grep -r pam_ssh /etc/pam.d|grep auth
> /etc/pam.d/system:#auth sufficient pam_ssh.so no_warn try_first_pass
> /etc/pam.d/ftp:#auth sufficient pam_ssh.so no_warn try_first_pass
> /etc/pam.d/ftpd:#auth sufficient pam_ssh.so no_warn try_first_pass
> /etc/pam.d/telnetd:#auth sufficient pam_ssh.so no_warn try_first_pass
> /etc/pam.d/xdm:#auth sufficient pam_ssh.so no_warn try_first_pass
> /etc/pam.d/imap:#auth sufficient pam_ssh.so no_warn try_first_pass
> /etc/pam.d/other:#auth sufficient pam_ssh.so no_warn try_first_pass
> /etc/pam.d/sshd:#auth sufficient pam_ssh.so no_warn try_first_pass
> /etc/pam.d/pop3:#auth sufficient pam_ssh.so no_warn try_first_pass


The implications of uncommenting these are not explained in the files
though.

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.

I would really like to see nullok support removed from pam_ssh.

Why is it even in the remote service files as an example when it is
dangerous in those contexts?

I find the pam configuration files overly complex and error-prone to
begin with, but to discover that there's such a bombshell sitting there
is concerning.

--
Regards,
Bryan Drewery

[Eric van Gyzen]

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