OpenSSH two-factor authentication combined with Kerberos / PubKeyAuth
Damien Miller
djm at mindrot.org
Tue May 5 12:34:26 AEST 2015
On Mon, 4 May 2015, Gy?rgy Demarcsek Ifj. wrote:
> Dear OpenSSH Development Team,
>
> I'm writing because I have trouble implementing a relatively
> straightforward authentication scenario with OpenSSH Server and I could not
> find any useful information by googling and probably you are my best choice
> to turn to because you must be the most familiar with the internals of
> OpenSSH.
>
> I'm trying to implement two-factor authentication for OpenSSH. The
> environment is Centos 7 (kernel: 3.10.0-229.1.2.el7.x86_64) with
> OpenSSH_6.6.1p1, OpenSSL 1.0.1e-fips 11 Feb 2013. We have Active Directory
> (LDAP) + Kerberos deployed. The specification is as follows:
It looks like your 2nd factor is going via PAM. This makes things
difficult (see below).
> - A user with an existing, valid Kerberos ticket must be asked only for
> the second factor
This is pretty easy using AuthenticationMethods
> - A user without an existing, valid Kerberos ticket must be asked for both
> his password and a second factor
This might be tricky if you are using a challenge/response 2nd factor
because both would go via PAM and there is no signalling between
sshd and the PAM stack that could be used to tell the latter that it
needs to ask for password+challenge/response rather than just password.
> - Local users (no LDAP acc.) should be able to authenticate with their
> local passwords
The only way this could be expressed in sshd is by putting all local
users into a group and then using "Match group" to vary their
AuthenticationMethods.
> - The second factor must not be offered before the first one
AuthenticationMethods controls the ordering of the methods offered,
so this should be possible.
> - Besides Kerberos, public key authentication should be also accepted as
> first factor if available
Subject to the caveats about, this can be done with AuthenticationMethods
too.
> - The feature should be able to be limited to a set of users - others just
> get let in with their passwords
Again, you'll need to set this up using groups.
> For performing the second factor's authentication process, there is 3rd
> party a PAM module available that knows nothing about Kerberos. So here is
> what I did:
>
> Put these lines into /etc/ssh/sshd_config:
...
> KerberosAuthentication yes
> KerberosOrLocalPasswd yes
If PAM is handling the password authentication, them I'm not sure whether
this will make much difference.
> # Kerberos / Public Key + PAM
> AuthenticationMethods gssapi-with-mic,keyboard-interactive:pam
> publickey,keyboard-interactive:pam password,keyboard-interactive:pam
The problem here is the last stanza: password,keyboard-interactive:pam
since PAM is handling password authentication under the hood too, but
PAM password authentication is a bit of a hack and only works when the
PAM configuration makes a single password prompt and expects a single
reply. Your PAM stack wants a password and a 2FA response, so the
'password' authn method won't work.
I don't know how to solve this with the current signalling between
sshd and PAM sorry.
> Now for Kerberos, this does almost everything I wanted to achieve. However,
> for local accounts, it results in two subsequent password prompts. This is
> my main problem here. This is because in this case the path
> "password,keyboard-interactive:pam"
> is used,as expected. (I need this auth. path so someone with a Kerberos
> account but without a valid ticket can get a ticket by entering the
> password then the OTP.) If I remove the password-auth substack completely
> from the PAM config, then Kerberos accounts remain working and local
> accounts remain not working. To me, it seems like the KerberosOrLocalPasswd
> yes statement gets ignored, because UsePAM yes is also present. However,
> sshd really keeps using KDC for password validation, because otherwise it
> would not work for LDAP accounts either.
It's probably using kerberos via PAM.
> So my scenario I think is not too complex or ambitious in any way, but I
> still could not find a clear way to implement it despite I spent days
> researching and experimenting. Could you please help me find a solution?
It might be possible to enhance sshd's signalling to PAM by stashing
something in a _SSHD_COMPLETED_AUTH PAM environment variable (or
somesuch) that modules could use to decide how to proceed, but I'm years
rusty with PAM. Maybe Darren or someone else who's more familiar could
suggest something.
-d
More information about the openssh-unix-dev
mailing list