Bug 2980

Summary:

New feature: Configure PAM Service Name in sshd_config

Product:

Portable OpenSSH

Reporter:

Eric Price <corvuscorax>

Component:

PAM support

Assignee:

Assigned to nobody <unassigned-bugs>

Status:

CLOSED DUPLICATE

Severity:

enhancement

CC:

djm

Priority:

Keywords:

low-hanging-fruit, patch

Version:

-current

Hardware:

All

OS:

Linux

Attachments:

Description	Flags
Patch to openssh-portable implementing above feature	none
patch including session handling fixes	none

Description Eric Price 2019-03-14 08:43:45 AEDT

Created attachment 3252 [details]
Patch to openssh-portable implementing above feature

I ran into a problem setting up 2 factor authentication with OpenSSH-portable and PAM.

The issue is, although openssh uses several different authentication mechanisms with different interaction capabilities, each of which use PAM as a backend, there is only a single service name, and as such only a single PAM configuration that needs to serve all of them.

This isn't flexible enough for more complex usecases. A detailed explanation of the problem and possible workarounds is here:

https://pastebin.com/SuCG6dft

The proper way of solving this is IMHO a more flexible way to interact with PAM, using a configurable PAMServiceName, which then can be overridden in Match directives based on remote host, user, ...

Since both PasswordAuthentication and ChallengeResponseAuthentication use PAM, it also makes sense to have a separate PasswordPAMServiceName, allowing a different PAM service configuration for this non-interactive version.

I took the liberty of implementing this suggestion.

From the man-page:

     PAMServiceName
             Specifies the service identifier to be used for
             pluggable authentication modules (PAM).  If set to
             none, the sshd executable name (usually sshd) is
             used.  If set to name, authentication options can be
             configured in a matching file in /etc/pam.d/name.
             The default is none.

    PasswordPAMServiceName
             Specifies the service identifier to be used for
             pluggable authentication modules (PAM) for
             PasswordAuthentication only. This is only used for
             the authentication (auth) PAM aspect. For account
             and session management, as well as
             ChallengeResponseAuthentication, the service name
             set in PAMServiceName is applied. This can be help‐
             ful to implement 2 factor authentication.  Example:

                   AuthenticationMethods
                   "publickey,keyboard-interactive password,keyboard-interactive"
                   PAMServiceName sshd_2factor
                   PasswordPAMServiceName sshd_password

             In this example, the challenge response authentica‐
             tion would ask the user for the second factor, for
             example an OATH token, while the first factor could
             be either provided by ssh-key or password. This
             requires two different PAM configurations to be
             used, in this example /etc/pam.d/sshd_2factor and
             /etc/pam.d/sshd_password. If set to none, the value
             of PAMServiceName is used.  The default is none.


I also filed a pull request on github under:

https://github.com/openssh/openssh-portable/pull/122

the very same patch is also attached below. I wasn't sure which is the preferred channel to contribute to this project.

I'm looking forward to your feedback :-)

cheers

Eric

Comment 1 Eric Price 2019-03-14 11:02:22 AEDT

I did some digging in the bug database and the dev mailing list.
Looks like I'm not the first person in need of that feature.

A first implementation was first suggested on the dev mailinglist
2 decades ago:

https://marc.info/?l=openssh-unix-dev&m=95840880026194&w=2

with code provided and a configurable flag PAMService in sshd_config

This was in OpenSSH 1.1, so no support for multiple AuthMethods, and no support for Match directives, since OpenSSH didn't have that yet.

-- There was no followup discussion on the mailing list and the patch was never included in the codebase.

Then there is a bug from 2015
https://bugzilla.mindrot.org/show_bug.cgi?id=2102
with multiple implementations which has been marked as a duplicate of
https://bugzilla.mindrot.org/show_bug.cgi?id=2246

This implemnentation takes a different route and assigns a prefix with a suffix for every single auth mechanism - including those that do not even use PAM for the auth procedure but only for session and account maintenance.

IMHO that is overkill, and lead to a interesting discussion of using macros in the arguments.

Several implementations of this exist on both mailinglist and attachments, but again none of them were implemented, the bug is still open.

I would request to not mark this bug as a duplicate, as the approach to solving the problem (not necessarily its implementation) is IMHO superior to the macro approach.

The generalized approach is:

- Use a generic PAMServiceName for the pam session for (account) and (session)

Use authentication method specific overrides only for (auth) and only for authentication methods that are actually PAM based.

AFAIK at the moment only ChallengeResponse/KeyboardInteractive and PasswordAuthentication use PAM for auth, so a single additional flag would be sufficient at the moment to distinguish these cases.

This is also necessary due to the difference in capabilities (interactive versus dumbfired)

Other authentication methods, such as keybased or kerberos only use PAM for account and session management after authentication succeeded (if UsePAM is true)

if in the future additional PAM (auth) based variants get added, they could introduce their own configuration flags to override PAMServiceName as needed - possibly in the form of <AuthMethodName>PAMServiceName

Most importantly this does not conflict with the cases in which the login procedure requests multiple authentication methods in series, as obviously only one pam service can be responsible for session management after all of them succeeded.

Does this make sense?

Comment 2 Eric Price 2019-03-14 20:33:03 AEDT

Looking some more into openssh's history, there was also

https://bugzilla.mindrot.org/show_bug.cgi?id=1041

Yet another attempt to implement this as a parameter.
Since this is from 2005 it predates Match directives. As indicated in the bug comments, since there could have only been a single name set in the config, this would have offered no advantage over the "symlink" method, where a separate sshd process is started under a different name.


I had a deeper look into the patch supplied with

https://bugzilla.mindrot.org/show_bug.cgi?id=2246

needless to say, the patch does not work with the latest version of openssh ;) But it includes a couple of important bugfixes regarding session management and state consistency that I should probably incorporate into my solution.

Comment 3 Eric Price 2019-03-14 21:50:44 AEDT

Created attachment 3253 [details]
patch including session handling fixes

Comment 4 Damien Miller 2019-06-07 14:57:02 AEST

I'll merge these two bugs - let's continue discussion on the previous bug as there is some history and context there.

*** This bug has been marked as a duplicate of bug 2246 ***

Comment 5 Damien Miller 2021-04-23 15:09:20 AEST

closing resolved bugs as of 8.6p1 release