Bug 1263133

Summary:	openssh multi factor authentication.
Product:	[Fedora] Fedora	Reporter:	Maciej Żenczykowski <zenczykowski>
Component:	openssh	Assignee:	Jakub Jelen <jjelen>
Status:	CLOSED EOL	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	22	CC:	jjelen, mattias.ellert, mgrepl, plautrba, tmraz, zenczykowski
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	All
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-07-19 19:56:52 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Maciej Żenczykowski 2015-09-15 07:59:01 UTC

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.

Comment 1 Jakub Jelen 2015-09-17 10:02:22 UTC

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.

Comment 2 Maciej Żenczykowski 2015-09-17 10:30:59 UTC

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!

Comment 3 Maciej Żenczykowski 2015-09-17 10:35:33 UTC

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!

Comment 4 Maciej Żenczykowski 2015-09-17 10:36:30 UTC

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.

Comment 5 Jakub Jelen 2015-09-17 16:34:41 UTC

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

Comment 6 Maciej Żenczykowski 2015-09-17 17:34:00 UTC

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?

Comment 7 Jakub Jelen 2015-09-18 07:04:14 UTC

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.

Comment 8 Maciej Żenczykowski 2015-09-18 17:52:45 UTC

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.

Comment 9 Jakub Jelen 2016-07-19 10:33:04 UTC

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.

Comment 10 Fedora End Of Life 2016-07-19 19:56:52 UTC

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.