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 _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
