Hi everyone,
I saw couple of discussion around in this list as well as others about how to exploit ppolicy with ssh : here are some thought.
Currently, I am in a situation where I have inserted my users public ssh keys in ldap (openssh-ldappubkey shema) and instructed sshd to consult ldap for ssh public keys, adding in ssh_config :
AuthorizedKeysCommand /usr/bin/sss_ssh_authorizedkeys
I also have authorized password authentication , in ssh_config:
PasswordAuthentication yes
My current policy is the following :
- All my users must have a password in ldap (that is used by applications other than ssh)
- not all my users may have an ssh key (some never use ssh)
Everything works as I want.
I now want to introduce ppolicy overlay and would like to enforce rules for password management even for users that mainly use ssh keys.
Practically and basically : when a user with valid ssh key ask for an ssh connexion, I would like ssh to behave exactly as if this user had typed a correct "loging/password" and therefore check for ppolicy situation before granting access.
aka : - if the account is 'ppolicy desactivated', ssh would refuse to provide the session
- if the password is "ppolicy oudated", then ssh would warn to change it (and decrease 'pwdGraceAuthnLimit*'*?)
... and so on.
I thought about two options/alternatives to do that :
* try to tune pam (may be there would be a way to tell pam to check for user ppolicy fields once authentication has been done before granting access ?)
* add some sort of flag (aka: --ppolicy) to sss_ssh_authorizedkeys to instruct sss_ssh_authorizedkeys to check for user ppolicy (use 'ldap_default_bind_dn' as a binding user) and if there is an issue return a "ppolicy error message" rather than the user ssh key ?
These are just some thoughts.
I'm currently exploring the first option (but I'm not a 'pam' expert and I'm even not sure that the ssh authentication process goes through pam if a valid key is found, even with 'UsePAM yes').
I would appreciate any guidance, advices or experiences from you on that particular issue.
Thank you,
-- Olivier
Hi,
Addendum:
My current policy is the following :
- All my users must have a password in ldap (that is used by
applications other than ssh)
- not all my users may have an ssh key (some never use ssh)
Everything works as I want.
I realize that with my tuning ssh behave as such:
* if the user has no key in ldap then ssh ask for a login password
* if the user has a correct key in ldap then ssh grant access and don't ask for any login/password
* if the user has an incorrect key in ldap then ssh swithch to the login/password authentication process.
That means that if a bad sshkey is returned by "sss_ssh_authorizedkeys", then ppolicy will be checked and updated if necessary through the "login / password" process.
May be that could help : with a given flag "sss_ssh_authorizedkeys" could simply refuse to return the key in case of a "ppolicy issue".
-- Olivier
2015-04-15 12:10 GMT+02:00 Olivier ldap@guillard.nom.fr:
Hi everyone,
I saw couple of discussion around in this list as well as others about how to exploit ppolicy with ssh : here are some thought.
Currently, I am in a situation where I have inserted my users public ssh keys in ldap (openssh-ldappubkey shema) and instructed sshd to consult ldap for ssh public keys, adding in ssh_config :
AuthorizedKeysCommand /usr/bin/sss_ssh_authorizedkeys
I also have authorized password authentication , in ssh_config:
PasswordAuthentication yes
My current policy is the following :
All my users must have a password in ldap (that is used by applications other than ssh)
not all my users may have an ssh key (some never use ssh)
Everything works as I want.
I now want to introduce ppolicy overlay and would like to enforce rules for password management even for users that mainly use ssh keys.
Practically and basically : when a user with valid ssh key ask for an ssh connexion, I would like ssh to behave exactly as if this user had typed a correct "loging/password" and therefore check for ppolicy situation before granting access.
aka :
if the account is 'ppolicy desactivated', ssh would refuse to provide the session
if the password is "ppolicy oudated", then ssh would warn to change it (and decrease 'pwdGraceAuthnLimit*'*?)
... and so on.
I thought about two options/alternatives to do that :
try to tune pam (may be there would be a way to tell pam to check for user ppolicy fields once authentication has been done before granting access ?)
add some sort of flag (aka: --ppolicy) to sss_ssh_authorizedkeys to instruct sss_ssh_authorizedkeys to check for user ppolicy (use 'ldap_default_bind_dn' as a binding user) and if there is an issue return a "ppolicy error message" rather than the user ssh key ?
These are just some thoughts.
I'm currently exploring the first option (but I'm not a 'pam' expert and I'm even not sure that the ssh authentication process goes through pam if a valid key is found, even with 'UsePAM yes').
I would appreciate any guidance, advices or experiences from you on that particular issue.
Thank you,
-- Olivier
On (15/04/15 12:37), Olivier wrote:
Hi,
Addendum:
My current policy is the following :
- All my users must have a password in ldap (that is used by
applications other than ssh)
- not all my users may have an ssh key (some never use ssh)
Everything works as I want.
I realize that with my tuning ssh behave as such:
if the user has no key in ldap then ssh ask for a login password
if the user has a correct key in ldap then ssh grant access and don't ask for any login/password
if the user has an incorrect key in ldap then ssh swithch to the login/password authentication process.
That means that if a bad sshkey is returned by "sss_ssh_authorizedkeys", then ppolicy will be checked and updated if necessary through the "login / password" process.
May be that could help : with a given flag "sss_ssh_authorizedkeys" could simply refuse to return the key in case of a "ppolicy issue".
Your requirements seems to be similar as in tickets: https://fedorahosted.org/sssd/ticket/2364 https://fedorahosted.org/sssd/ticket/2534
The first feature is available in sssd-1.11 and the second one was recently added to sssd-1.12
Here is a sample config [sssd] services = nss, pam config_file_version = 2 domains = LDAP
[domain/LDAP] debug_level = 0xfff0 ldap_search_base = $DS_BASE_DN id_provider = ldap ldap_uri = ldap://$SERVER cache_credentials = True ldap_tls_cacert = /etc/openldap/certs/cacert.asc access_provider = ldap ldap_access_order = lockout ldap_pwdlockout_dn = cn=pwdconfig,ou=policies,$DS_BASE_DN
You can read more details in manual page sssd-ldap -> ldap_access_order
LS
Many thanks Lukas : very interesting.
I look at this.
--- Olivier
2015-04-15 13:40 GMT+02:00 Lukas Slebodnik lslebodn@redhat.com:
On (15/04/15 12:37), Olivier wrote:
Hi,
Addendum:
My current policy is the following :
- All my users must have a password in ldap (that is used by
applications other than ssh)
- not all my users may have an ssh key (some never use ssh)
Everything works as I want.
I realize that with my tuning ssh behave as such:
if the user has no key in ldap then ssh ask for a login password
if the user has a correct key in ldap then ssh grant access and don't ask for any login/password
if the user has an incorrect key in ldap then ssh swithch to the login/password authentication process.
That means that if a bad sshkey is returned by "sss_ssh_authorizedkeys", then ppolicy will be checked and updated if necessary through the "login / password" process.
May be that could help : with a given flag "sss_ssh_authorizedkeys" could simply refuse to return the key in case of a "ppolicy issue".
Your requirements seems to be similar as in tickets: https://fedorahosted.org/sssd/ticket/2364 https://fedorahosted.org/sssd/ticket/2534
The first feature is available in sssd-1.11 and the second one was recently added to sssd-1.12
Here is a sample config [sssd] services = nss, pam config_file_version = 2 domains = LDAP
[domain/LDAP] debug_level = 0xfff0 ldap_search_base = $DS_BASE_DN id_provider = ldap ldap_uri = ldap://$SERVER cache_credentials = True ldap_tls_cacert = /etc/openldap/certs/cacert.asc access_provider = ldap ldap_access_order = lockout ldap_pwdlockout_dn = cn=pwdconfig,ou=policies,$DS_BASE_DNYou can read more details in manual page sssd-ldap -> ldap_access_order
LS _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Olivier wrote:
My current policy is the following :
All my users must have a password in ldap (that is used by applications other than ssh)
not all my users may have an ssh key (some never use ssh)
Everything works as I want.
I realize that with my tuning ssh behave as such:
if the user has no key in ldap then ssh ask for a login password
if the user has a correct key in ldap then ssh grant access and don't ask for any login/password
if the user has an incorrect key in ldap then ssh swithch to the login/password authentication process.
That means that if a bad sshkey is returned by "sss_ssh_authorizedkeys", then ppolicy will be checked and updated if necessary through the "login / password" process.
May be that could help : with a given flag "sss_ssh_authorizedkeys" could simply refuse to return the key in case of a "ppolicy issue".
Note that password policy response controls can only be used when sssd actually tries to verify the user's password with a LDAP (simple) bind request. Obviously this won't work if you completely disabled passwort authc in sshd_config.
sss_ssh_authorizedkeys could check whether the password is expired by looking at attribute 'pwdChangedTime' (provided it's at least searchable for sssd) and generate a filter with the correct expiration time similar like in [1].
Another approach would be to configure the LDAP server to make user entry or at least the SSH key attribute invisible with ACL/ACI and a status flag. With this approach you can run a CRON job at the LDAP server setting the status flag and you don't have to implement the solution on all clients.
Ciao, Michael.
[1] http://ltb-project.org/wiki/documentation/ldap-scripts/checkldappwdexpiratio...
Thanks Michael,
Note that password policy response controls can only be used when sssd
actually tries to verify the user's password with a LDAP (simple)
bind request. Obviously this won't work if you completely disabled
passwort authc in sshd_config.
that is my fear. Since it sounds to me that sshd bypass the user password verification when authenticate over ssh key, I'm curious to see if those options will be relevant in my case. I'll let you know.
Best
--- Olivier
2015-04-15 14:07 GMT+02:00 Michael Ströder michael@stroeder.com:
Olivier wrote:
My current policy is the following :
All my users must have a password in ldap (that is used by applications other than ssh)
not all my users may have an ssh key (some never use ssh)
Everything works as I want.
I realize that with my tuning ssh behave as such:
if the user has no key in ldap then ssh ask for a login password
if the user has a correct key in ldap then ssh grant access and don't ask for any login/password
if the user has an incorrect key in ldap then ssh swithch to the login/password authentication process.
That means that if a bad sshkey is returned by "sss_ssh_authorizedkeys", then ppolicy will be checked and updated if necessary through the "login / password" process.
May be that could help : with a given flag "sss_ssh_authorizedkeys" could simply refuse to return the key in case of a "ppolicy issue".
Note that password policy response controls can only be used when sssd actually tries to verify the user's password with a LDAP (simple) bind request. Obviously this won't work if you completely disabled passwort authc in sshd_config.
sss_ssh_authorizedkeys could check whether the password is expired by looking at attribute 'pwdChangedTime' (provided it's at least searchable for sssd) and generate a filter with the correct expiration time similar like in [1].
Another approach would be to configure the LDAP server to make user entry or at least the SSH key attribute invisible with ACL/ACI and a status flag. With this approach you can run a CRON job at the LDAP server setting the status flag and you don't have to implement the solution on all clients.
Ciao, Michael.
[1] http://ltb-project.org/wiki/documentation/ldap-scripts/ checkldappwdexpiration
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
On Wed, Apr 15, 2015 at 02:35:08PM +0200, Olivier wrote:
Thanks Michael,
Note that password policy response controls can only be used when sssd
actually tries to verify the user's password with a LDAP (simple)
bind request. Obviously this won't work if you completely disabled
passwort authc in sshd_config.
that is my fear. Since it sounds to me that sshd bypass the user password verification when authenticate over ssh key, I'm curious to see if those options will be relevant in my case. I'll let you know.
As Lukas said, SSSD also checks the password expiration during LDAP access control.
I share Michael's sentiment about this being a bit of a misfeature, since the password controls should only apply to password operations, but many users requested this feature. It's not enabled by default btw.
Jakub Hrozek wrote:
On Wed, Apr 15, 2015 at 02:35:08PM +0200, Olivier wrote:
Thanks Michael,
Note that password policy response controls can only be used when sssd
actually tries to verify the user's password with a LDAP (simple)
bind request. Obviously this won't work if you completely disabled
passwort authc in sshd_config.
that is my fear. Since it sounds to me that sshd bypass the user password verification when authenticate over ssh key, I'm curious to see if those options will be relevant in my case. I'll let you know.
As Lukas said, SSSD also checks the password expiration during LDAP access control.
I share Michael's sentiment about this being a bit of a misfeature, since the password controls should only apply to password operations, but many users requested this feature. It's not enabled by default btw.
Please don't get me wrong: I don't regard this to be a mis-feature. Actually I disable SSH keys when passwords are expired because it fits the expectation that people cannot login anymore at all.
But I'd rather solve this problem at the LDAP server side.
Ciao, Michael.
sssd-users@lists.fedorahosted.org
-
Jakub Hrozek -
Lukas Slebodnik -
Michael Ströder -
Olivier