sss_ssh_authorizedkeys: add a flag for ppolicy ?

[Olivier]

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]

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 :
> 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

[Pavel Reichl]

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
> [e-mail]
> 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?

[Olivier]

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 :
> 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 [e-mail]://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
> [e-mail]
> https://lists.fedorahosted.org/mailman/listinfo/sssd-devel

[Pavel Reichl]

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 <[e-mail] 
> >:
> 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
> > [e-mail]  <mailto:[e-mail]>
> > 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?
>
> _______________________________________________
> sssd-devel mailing list
> [e-mail]
> <mailto:[e-mail]>
> https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
>
>
>
>
> sssd-devel mailing list
> [e-mail]
> 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-users] sss_ssh_authorizedkeys: add a flag for ppolicy ?

[Michael Ströder]

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...