I would like a way to implement the following policy: From trusted IPs accept either a publickey or a password. From untrusted IPs accept either a publickey+otp or a password+otp. (or maybe publickey+password or password+otp, not sure which is more desirable) Currently I use the following to implement password+OTP for untrusted IPs and password for trusted IPs. /etc/pam.d/password-auth-ac includes something like the following: auth required pam_env.so auth [success=3 default=ignore] pam_access.so noaudit accessfile=/etc/security/access-local.conf auth required pam_unix.so try_first_pass auth sufficient pam_google_authenticator.so auth [default=1] pam_permit.so auth sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 1000 quiet_success auth required pam_deny.so /etc/security/access-local.conf contains: # only allow from local IP range and console + : ALL : 127.0.0.0/8 ::ffff:127.0.0.0/104 ::1 + : ALL : 10.0.0.0/8 ::ffff:10.0.0.0/104 + : ALL : 172.16.0.0/12 ::ffff:172.16.0.0/108 + : ALL : 192.168.0.0/16 ::ffff:192.168.0.0/112 + : ALL : tty0 tty1 tty2 tty3 tty4 tty5 tty6 tty7 tty8 tty9 tty10 tty11 tty12 + : ALL : vc/0 vc/1 vc/2 vc/3 vc/4 vc/5 vc/6 vc/7 vc/8 vc/9 vc/10 vc/11 vc/12 + : ALL : ttyS0 ttyS1 ttyS2 ttyS3 + : ALL : ttyUSB0 ttyUSB1 ttyUSB2 - : ALL : ALL /etc/ssh/sshd_config includes: Match Address 127.0.0.0/8,::ffff:127.0.0.0/104,::1,... AuthenticationMethods publickey keyboard-interactive:pam Match All AuthenticationMethods publickey,keyboard-interactive:pam keyboard-interactive:pam From trusted IPs it will indeed either accept publickey or password, however from untrusted IPs this will require either publickey+password+otp or password+otp. I have not been able to figure out a way to get pam to skip google authenticator if publickey authentication has already been accepted. It seems like I should able to if off of *something* but I can't figure out what that would be. I should be able to test for something with pam_succeed_if.so which can currently inspect: user, uid, gid, shell, home, ruser, rhost, tty and service. I think tty or service are the best choices. Currently they appear to be unconditional: Service name (PAM_SERVICE): [sshd] Name of the controlling terminal (PAM_TTY): [ssh] (strictly speaking I think sshd is the name of the binary, but that doesn't help us) It would be nice if I could write: AuthenticationMethods publickey,keyboard-interactive:pam:ssh-with-publickey keyboard-interactive:pam:ssh OR AuthenticationMethods publickey,keyboard-interactive:pam:sshd-with-publickey keyboard-interactive:pam:sshd To specify the PAM_TTY/PAM_SERVICE so that I could either match on it with pam_succeed_if.so tty/service or (in the PAM_SERVICE case) with an outright new /etc/pam.d/sshd-with-publickey configuration.
Hi Maciej, this is interesting question, but it is more appropriate to post to some mailing list, Q&A site or discussion board. Bugzilla is for filling bug reports and feature requests for our products. Setting up different policies for different networks was always complicated in openssh, especially when you want to use OTP, which is not provided directly by openssh. Using AuthenticationMethods in this form "keyboard-interactive:pam:sshd-with-publickey" seems to me over-complicated. But there is upstream bug with patch that was never applied, that should help to solve your problem: https://bugzilla.mindrot.org/show_bug.cgi?id=2102 It is providing PAMServiceName configuration option, that you can change for different policies and then take care of the rest in PAM. If you think it would help you, I can build you testing package and we can consider adding this option to Fedora.
From a cursory examination of the linked bugs description it does seem like that allows one to do exactly what I would like. A testing package would be nice!
Ugh, copy and paste error and collisions. What I wanted to say, is that the default should probably still be __progname and not sshd for backwards compatibility with existing ssh daemon configuration.
I rebuilt for you recent package with this patch. Can you test if it works for you? I will try to talk with upstream about accepting this change. There should be no blocker, since all PAM is portable-only feature in openssh. http://koji.fedoraproject.org/koji/taskinfo?taskID=11125162
I'm not seeing a way to download binary or src packages (to rebuild myself) from the above link, and I can't seem to find this through a normal search for openssh on koji. Is it hidden somehow?
Sure. It is scratch build so it is not visible in any search. But by clicking on x86_64 architecture you will get to: http://koji.fedoraproject.org/koji/taskinfo?taskID=11125163 Where you can download both srpm, but also rpms for this architecture and for Fedora 22.
Thanks. I've successfully downloaded and installed the package. However, I've run into a bit of a problem with actually configuring this. AFAICT while I can configure a different pam service type for different users and or different src ips, I can't configure a different pam service based on if you've already authenticated via public key or not, because that's not something I can 'Match' on. I do like the patch, but it doesn't seem like it will allow me to implement my request. I'll play around with it some more.
Can you check https://cern-cert.github.io/pam_2fa/ if it can solve your problems? The required feature for this 2fa was pushed as the latest update to Fedora 24. Note, that it is not using google authenticator, but pam_u2f from CERN, but it should do the same job. I didn't try that yet, but this could be a universal solution for the second factor.
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.