Multiple PAM stacks for multi-factor auth

[Iain Morgan]

On Fri, Mar 27, 2015 at 11:44:00 -0700, James Wilson wrote:
> I'd like to permit authentication by either public key followed by
> second factor, OR password followed by second factor. It seems the
> sshd configuration ought to be:
> 
> UsePam yes
> PubkeyAuthentication yes
> PasswordAuthentication yes
> ChallengeResponseAuthentication yes
> AuthenticationMethods publickey,keyboard-interactive
> password,keyboard-interactive
> 
> For most purposes, "UsePam yes" makes password and
> keyboard-interactive do the same thing - run the auth stack in
> sshd's PAM config. Thus the second choice in AuthenticationMethods
> is repeating the same policy, where what I want is to do a password
> check via pam_unix, and then run the 2nd-factor module. I can
> combine the checks in /etc/pam.d/sshd to make it work and then use a
> single "keyboard-interactive" method
> 
> auth requisite pam_unix.so
> auth required pam_duo/yubico/google_authenticator/etc.so
> 
> but now the "publickey,keyboard-interactive" method requires public
> key, then password, then 2nd factor, and I haven't found a solution.
> I searched and found the Fedora encountered a similar problem and
> chose to add handling multiple PAM stacks. The discussion in
> http://fedoraproject.org/wiki/Features/MultiplePAMStacksInGDM is
> informative. Can OpenSSH add a way to run different rule sets in the
> syntax of AuthenticationMethods to make these configurations
> possible?

There have been some discussions about adding a PAMServiceName option
that would support a macro that is expanded to the authentication
method, but I'm not sure what the status is of any such patches.

Currently, sshd uses the basename of the sshd executable as the PAM
service name, so it is possible to (somewhat) simulate what you desire
by having two instances of sshd running; one using a renamed executable.
This has the disadvantage of requiring users to connect to a different
port or address depending upon how they wish to authenticate, but
otherwise will work.

There might be a way of getting this to work using z single instance
under very specific circumstances, but I don't know if what I'm about to
describe will actually work. If you are still using MD5 password hashes
and build sshd with md5 password support enabled, you could then avoid
PAM for password authentication. I'm assuming that you would need to set
UsePAM to "no," and you might need to specify pam as the subtype for
keyboard-interactive in the AuthenticationMethods line.

I haven't had an opportunity to try such a configuration, so I give not
guarantee as to whether it would work.

Extending the AuthenticationMethods syntax to support specifying the
service nzme for the PAM subtype might be interesting. I had not thought
of that before. I'm not sure if that apporach has any advantages over
the PAMServicename approach. The complication with the PAMServiceName
apporach is the expectation that the alternative PAM stacks would also
be used for the account stap, but an argument could be made for just
procesing the auth portion if the AuthenticationMethods subtype
approach were taken. So, it might be simplier, but might not be suitable
for all purposes.

-- 
Iain Morgan