SSH Key auth with expired Kerberos password

[Nathan Harper]

Hi all,

We have noticed some behaviour that we are trying to work out if it is
expected or not (or if this is an SSSD thing).   We have a pair of FreeIPA
replicas running on CentOS 7 (v4.5.x), with various CentOS 7 clients.
 Most clients aren't actually enrolled in FreeIPA, but are configured with:

id_provider = ldap
auth_provider = krb5

Authentication works as expected, plus password changes etc.   However, if
a user has added a public key to authorized_keys, the status of the
password is not considered and at no point is a user prompted to change
their password.   More importantly, if a user is disabled in FreeIPA, they
are still permitted to login using their SSH key.

I have checked the behaviour on a client that is enrolled, and it is better
(disabling a user does prevent access), but it still does not give any
indication about failed passwords.

Under most circumstances this wouldn't be too much of an issue, but we make
use of one application for remote access that does not know what to do with
an expired password, and instead just presents 'authentication failed'.

Any suggestions?

[Tony Brian Albers]

Morning,

We've had this issue and we found out that it is caused by the fact
that sshd when using key-based auth bypasses PAM authentication which
means that the kerberos server is never contacted.

So, don't use passwordless ssh.

Others might have more info on this, but the above solution(!) is
simple, stable and effective.

/tony

On Wed, 2018-11-07 at 21:53 +0000, Nathan Harper via FreeIPA-users
wrote:
>  
>  Hi all,
>  
>  We have noticed some behaviour that we are trying to work out if it
>  is expected or not (or if this is an SSSD thing).   We have a pair of
>  FreeIPA replicas running on CentOS 7 (v4.5.x), with various CentOS 7
>  clients.   Most clients aren't actually enrolled in FreeIPA, but are
>  configured with:
>  
>  id_provider = ldap
>  auth_provider = krb5
>  
>  Authentication works as expected, plus password changes etc. 
>   However, if a user has added a public key to authorized_keys, the
>  status of the password is not considered and at no point is a user
>  prompted to change their password.   More importantly, if a user is
>  disabled in FreeIPA, they are still permitted to login using their
>  SSH key.
>  
>  I have checked the behaviour on a client that is enrolled, and it is
>  better (disabling a user does prevent access), but it still does not
>  give any indication about failed passwords.
>  
>  Under most circumstances this wouldn't be too much of an issue, but
>  we make use of one application for remote access that does not know
>  what to do with an expired password, and instead just presents
>  'authentication failed'.
>  
>  Any suggestions?
>  _______________________________________________
>  FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
>  To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahoste
>  d.org
>  Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelin
>  es
>  List Archives: https://lists.fedorahosted.org/archives/list/freeipa-u
>  sers(a)lists.fedorahosted.org
>  
-- 
Tony Albers
Systems Architect
Systems Director, National Cultural Heritage Cluster
Royal Danish Library, Victor Albecks Vej 1, 8000 Aarhus C, Denmark.
Tel: [phone]

[Sumit Bose]

On Wed, Nov 07, 2018 at 09:53:03PM +0000, Nathan Harper via FreeIPA-users wrote:
>  Hi all,
>  
>  We have noticed some behaviour that we are trying to work out if it is
>  expected or not (or if this is an SSSD thing).   We have a pair of FreeIPA
>  replicas running on CentOS 7 (v4.5.x), with various CentOS 7 clients.
>   Most clients aren't actually enrolled in FreeIPA, but are configured with:
>  
>  id_provider = ldap
>  auth_provider = krb5
>  
>  Authentication works as expected, plus password changes etc.   However, if
>  a user has added a public key to authorized_keys, the status of the
>  password is not considered and at no point is a user prompted to change
>  their password.   More importantly, if a user is disabled in FreeIPA, they
>  are still permitted to login using their SSH key. 
If you are using the generic LDAP id_provider you might need to configure
access control for your needs. For this please see the ldap_access_order
option in the sssd-ldap man page.

>  
>  I have checked the behaviour on a client that is enrolled, and it is better
>  (disabling a user does prevent access), but it still does not give any
>  indication about failed passwords. 
IPA supports multiple authentication methods and although one might be
expired others might still work. E.g. you can use Smartcard
authentication with IPA and I guess you would be surprised if password
authentication would fail because your certificate on the Smartcard is
expired.


HTH

bye,
Sumit

>  
>  Under most circumstances this wouldn't be too much of an issue, but we make
>  use of one application for remote access that does not know what to do with
>  an expired password, and instead just presents 'authentication failed'.
>  
>  Any suggestions? 
>  _______________________________________________
>  FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
>  To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org
>  Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
> https://lists.fedorahosted.org/archives/list/[e-mail]...