OpenSSH, authentication, PAM

haertig · 03-25-2006, 12:10 PM

I have a question on how OpenSSH interacts with PAM.

I setup sshd_config to allow PubkeyAuthentication but not PasswordAuthentication. My key was accepted for authentication. Then I renamed my ~/.ssh directory as a test. No key available now, but it prompted me for a password (???)

I figured this was PAM, not SSHD, so I removed "UsePAM yes" from sshd_config, retested, and this proved that it was indeed PAM triggering the password prompt.

But I noticed something unexpected during this testing. It appears that when SSHD accepted my key for authentication, it still called PAM if UsePAM was in effect. I was still seeing the MOTD, lastlogin, email check, etc. from PAM. But the authentication part from PAM - which should ask for a password per my /etc/pam.d/ssh configuration - was NOT used. So does OpenSSH somehow pass a message on to PAM saying that I had already been authenticated? I would have expected to have to authenticate TWICE - once with a key for SSHD, and once with a password for PAM.

I think I would prefer to turn off all authentication in OpenSSH (allow nothing) and defer to PAM to authenticate. But I can't find any pam_pubkey (or similar) module in PAM. Does that strike anyone else as an odd thing to be omitted?

I'm just learning PAM, so please excuse my newbie-ness here. It appears from my testing that there would be no way to require BOTH pubkey AND password authentication with OpenSSH/PAM. I'm not saying that this level of paranoia is required. The suggestion is more a mental exercise in configuration to learn how these two packages interact.

unSpawn · 03-27-2006, 11:10 AM

(..) It appears that when SSHD accepted my key for authentication, it still called PAM if UsePAM was in effect. I was still seeing the MOTD, lastlogin, email check, etc. from PAM.
That's because of how a PAM stack works. On a regular PAM stack there's four module sections (authentication, account, password, session) that need to be worked through. AFAIK when UsePAM=no OpenSSH is expected to handle anything after authentication like session etc, etc checking itself else PAM will take care of it. BTW, note that PasswordAuthentication and UsePAM usage changes over releases: see "OpenSSH versions and PAM behaviour.": http://www.openssh.com/faq.html#3.15. (and one example where you would need UsePAM=yes is external auth like LDAP). BTW, have you tried UsePAM=no and renamed /etc/pam.d/sshd? Then it has no PAM stack config at all to interfere with tests (don't do that on a box you only have remote acess to).

But the authentication part from PAM - which should ask for a password per my /etc/pam.d/ssh configuration - was NOT used.
That's the wrong conclusion I think, because if I understand PAM, if a previous item in the same module section of the stack gets the auth done, the next item, when using args like use_authtok or use_first_pass or similar, will be just take the "OK" from the previous module and move on.

I would have expected to have to authenticate TWICE - once with a key for SSHD, and once with a password for PAM.
Try removing any args like use_authtok or use_first_pass or similar and try again, but again, don't do that on a box you only have remote acess to.

I think I would prefer to turn off all authentication in OpenSSH (allow nothing) and defer to PAM to authenticate.
I don't think that'll work and I don't see anything there that enhances the security posture of the service. If you have idea's otherwise I'd sure like to hear it.

I'm not saying that this level of paranoia is required.
I wouldn't either. There's enough established ways around to secure the service w/o having to resort to all kinds of hacks.

haertig · 03-27-2006, 11:48 AM

Thanks for the reply.

Quote:

But the authentication part from PAM - which should ask for a password per my /etc/pam.d/ssh configuration - was NOT used.
That's the wrong conclusion I think, because if I understand PAM, if a previous item in the same module section of the stack gets the auth done, the next item, when using args like use_authtok or use_first_pass or similar, will be just take the "OK" from the previous module and move on.

And this is exactly what is confusing me. There is no "previous module" that would have done the authentication in PAM. Nor any use_authtok or use_first_pass args in my setup. The authentication was pubkey, which PAM does not support as far as I can tell. So the authentication would have had to been done by sshd, not by a PAM module. So how would PAM have known that sshd already did the authentication? I know the PAM stack is being called, because I see the behavior triggered by the "session" directives (MOTD, email check, etc.) But I don't see the expected behavior from the "auth" directives. It's as if the "auth" part of the PAM stack was bypassed because sshd had already done the authentication. What I don't get is how this fact is communicated from sshd to PAM so PAM knows to skip the auth part.

Here are the auth directives from my ssh PAM stack:

Code:

auth       required     pam_nologin.so
auth       required     pam_env.so # [1]
@include common-auth

And common-auth looks like this:

Code:

auth    required        pam_unix.so nullok_secure

I don't know what that nullok_secure arg is. It doesn't seem to be documented anywhere I can find. This is PAM as default installed by Debian SID, so maybe it's some Debian-specific thing added by the developers. Maybe nullok_secure is my missing link between sshd and PAM???

Quote:

I think I would prefer to turn off all authentication in OpenSSH (allow nothing) and defer to PAM to authenticate.
I don't think that'll work and I don't see anything there that enhances the security posture of the service. If you have idea's otherwise I'd sure like to hear it.

No, I don't expect this would enhance security. If anything, it might provide some minor maintenance benefit. Namely, all authentication system-wide being done in one place - by PAM - and not by seperate applications like sshd. Of course, with no pubkey PAM module I'd be kind of stuck...

Thanks again for your reply!

unSpawn · 03-27-2006, 01:40 PM

It's as if the "auth" part of the PAM stack was bypassed because sshd had already done the authentication.
That looks like a valid conclusion. I mean, why do password auth if ssh passphrase auth went OK?

What I don't get is how this fact is communicated from sshd to PAM so PAM knows to skip the auth part.
For that you'll have to read the PAM devel HOWTO and read the OpenSSH code (which is clean to read and not like a gazillion of lines).

I don't know what that nullok_secure arg is. It doesn't seem to be documented anywhere I can find.

Quote:

The nullok_secure option was added to support passwordless pam_unix logins only from ttys listed in /etc/securetty. It was added because nullok was not considered an appropriate option to configure for all services, but there was a need to support passwordless root logins on tty2 on newly installed Debian systems when base-config has not yet been run to configure a root password.

If anything, it might provide some minor maintenance benefit. Namely, all authentication system-wide being done in one place - by PAM - and not by seperate applications like sshd.
If it's only about centralising auth then I think you lose more than you gain, because I can't see how this would keep/make the system equally/more secure.