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
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...
On 04/15/2015 12:10 PM, Olivier wrote:
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
sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
Hello Olivier,
are you aware of 'ldap_access_order' option and its values (see man sssd-ldap) , could that help you?
Sorry to have missed that : sounds interesting really.
stay to see the articulation between these sssd options, sss_ssh_authorizedkeys and ssh the authentication process.
I look at it.
-- Olivier
2015-04-15 13:20 GMT+02:00 Pavel Reichl preichl@redhat.com:
On 04/15/2015 12:10 PM, Olivier wrote:
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
sssd-devel mailing listsssd-devel@lists.fedorahosted.orghttps://lists.fedorahosted.org/mailman/listinfo/sssd-devel
Hello Olivier,
are you aware of 'ldap_access_order' option and its values (see man sssd-ldap) , could that help you?
sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
On 04/15/2015 01:46 PM, Olivier wrote:
Sorry to have missed that : sounds interesting really.
stay to see the articulation between these sssd options, sss_ssh_authorizedkeys and ssh the authentication process.
I look at it.
-- Olivier
2015-04-15 13:20 GMT+02:00 Pavel Reichl <preichl@redhat.com mailto:preichl@redhat.com>:
On 04/15/2015 12:10 PM, Olivier wrote: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 _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org <mailto:sssd-devel@lists.fedorahosted.org> https://lists.fedorahosted.org/mailman/listinfo/sssd-develHello Olivier, are you aware of 'ldap_access_order' option and its values (see man sssd-ldap) , could that help you? _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org <mailto:sssd-devel@lists.fedorahosted.org> https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
Olivier,
could we stop posting in this thread and continue instead solely in the thread you created on sssd-user list which is better suited for this purpose?
Thanks!
sssd-devel@lists.fedorahosted.org