Hi,
in our environment all NFS shares are mounted with 'sec=krb5' and user homedirs are on NFS. So when users logs in via SSH they need a kerberos ticket to read their homedir. SSH with GSSAPIAuthentication would solve this, and of course user/password works as well. But for different reasons we want to restrict login to ssh keys only, with the key stored non-exportable on a hard token (smartcard/yubikey) and the public part stored in AD (accessed by using sshd config option 'AuthorizedKeysCommand /usr/bin/sss_ssh_authorizedkeys'). The problem is that the user does not get a kerberos ticket on login with this scheme, forcing them to use 'kinit' which requires password which we dont want to use.
I've read
https://bugzilla.redhat.com/show_bug.cgi?id=1017651
and
https://fedorahosted.org/freeipa/ticket/4000
The bugzilla is old but contains new, relevant input from users but no new comments from any devs - are there any new thoughts of making SSSD/sshd capable of retrieving a kerberos TGT for a user logged in with ssh keys? I understand the security concerns, but having the keys non-exportable on a hard token and storing the public part in AD/IdM should solve those issues, dont you think?
Right now we are stuck between two security principles (requiring krb auth for NFS access and using a secure ssh key setup for access) that dont play nice with each other.
Regards
Adam
possible workaround for us, since we already use 'GSSAPIAuthentication', is to configure sshd to require both:
AuthenticationMethods gssapi-with-mic,publickey
But this requires that the user has a valid TGT to start with, so the question can still be of interest for others.
//Adam
________________________________ From: externaly-forwarded@smhi.se externaly-forwarded@smhi.se on behalf of Winberg Adam Adam.Winberg@smhi.se Sent: 17 November 2020 08:00 To: sssd-users@lists.fedorahosted.org Subject: [SSSD-users] SSH keys and kerberos ticket
Hi,
in our environment all NFS shares are mounted with 'sec=krb5' and user homedirs are on NFS. So when users logs in via SSH they need a kerberos ticket to read their homedir. SSH with GSSAPIAuthentication would solve this, and of course user/password works as well. But for different reasons we want to restrict login to ssh keys only, with the key stored non-exportable on a hard token (smartcard/yubikey) and the public part stored in AD (accessed by using sshd config option 'AuthorizedKeysCommand /usr/bin/sss_ssh_authorizedkeys'). The problem is that the user does not get a kerberos ticket on login with this scheme, forcing them to use 'kinit' which requires password which we dont want to use.
I've read
https://bugzilla.redhat.com/show_bug.cgi?id=1017651
and
https://fedorahosted.org/freeipa/ticket/4000
The bugzilla is old but contains new, relevant input from users but no new comments from any devs - are there any new thoughts of making SSSD/sshd capable of retrieving a kerberos TGT for a user logged in with ssh keys? I understand the security concerns, but having the keys non-exportable on a hard token and storing the public part in AD/IdM should solve those issues, dont you think?
Right now we are stuck between two security principles (requiring krb auth for NFS access and using a secure ssh key setup for access) that dont play nice with each other.
Regards
Adam
On Tue, Nov 17, 2020 at 08:04:47AM +0000, Winberg Adam wrote:
possible workaround for us, since we already use 'GSSAPIAuthentication', is to configure sshd to require both:
AuthenticationMethods gssapi-with-mic,publickey
But this requires that the user has a valid TGT to start with, so the question can still be of interest for others.
Hi,
I think SSSD is not the right place to start this discussion. Imo the first question is how you can get a Kerberos ticket with a ssh public-private key pair. When just looking at the keys pkinit might be a point to start with since certificates are basically a public-private key pair with meta-data and a signature. But I think the meta-data and especially the signature are key points to make pkinit secure. Additionally pkinit uses a server-side certificate as well to allow the client to trust the server. Finally if all this is sorted out and a RFC is written and accepted, you have to convince vendors, especially Microsoft, to support this.
There might be an alternative way. p11-kit supports forwarding the PKCS#11 Smartcard access over an ssh connection. So it might be possible to open the ssh connection with the ssh key, forward the PKCS#11 access to the remote host and then use a pam module in the session phase to do a pkinit with the forwarded PKCS#11. The of course means you need a certificate on the hardware token as well. What I currently do not know is if a PIN input is required of if the PIN can be somehow kept in memory of the local computer similar to what the ssh agent would do.
SSSD might be able to provide the needed pam operations during the session phase but if you want to start experimenting with forwarded PKCS#11 I think using pam_exec to call kinit with the required pkinit option would be a good start.
HTH
bye, Sumit
//Adam
From: externaly-forwarded@smhi.se externaly-forwarded@smhi.se on behalf of Winberg Adam Adam.Winberg@smhi.se Sent: 17 November 2020 08:00 To: sssd-users@lists.fedorahosted.org Subject: [SSSD-users] SSH keys and kerberos ticket
Hi,
in our environment all NFS shares are mounted with 'sec=krb5' and user homedirs are on NFS. So when users logs in via SSH they need a kerberos ticket to read their homedir. SSH with GSSAPIAuthentication would solve this, and of course user/password works as well. But for different reasons we want to restrict login to ssh keys only, with the key stored non-exportable on a hard token (smartcard/yubikey) and the public part stored in AD (accessed by using sshd config option 'AuthorizedKeysCommand /usr/bin/sss_ssh_authorizedkeys'). The problem is that the user does not get a kerberos ticket on login with this scheme, forcing them to use 'kinit' which requires password which we dont want to use.
I've read
https://bugzilla.redhat.com/show_bug.cgi?id=1017651
and
https://fedorahosted.org/freeipa/ticket/4000
The bugzilla is old but contains new, relevant input from users but no new comments from any devs - are there any new thoughts of making SSSD/sshd capable of retrieving a kerberos TGT for a user logged in with ssh keys? I understand the security concerns, but having the keys non-exportable on a hard token and storing the public part in AD/IdM should solve those issues, dont you think?
Right now we are stuck between two security principles (requiring krb auth for NFS access and using a secure ssh key setup for access) that dont play nice with each other.
Regards
Adam
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.o...
On Wed, Nov 18, 2020 at 08:31:41AM +0100, Sumit Bose wrote:
On Tue, Nov 17, 2020 at 08:04:47AM +0000, Winberg Adam wrote:
possible workaround for us, since we already use 'GSSAPIAuthentication', is to configure sshd to require both:
AuthenticationMethods gssapi-with-mic,publickey
But this requires that the user has a valid TGT to start with, so the question can still be of interest for others.
Hi,
I think SSSD is not the right place to start this discussion. Imo the first question is how you can get a Kerberos ticket with a ssh public-private key pair. When just looking at the keys pkinit might be a point to start with since certificates are basically a public-private key pair with meta-data and a signature. But I think the meta-data and especially the signature are key points to make pkinit secure. Additionally pkinit uses a server-side certificate as well to allow the client to trust the server. Finally if all this is sorted out and a RFC is written and accepted, you have to convince vendors, especially Microsoft, to support this.
There might be an alternative way. p11-kit supports forwarding the PKCS#11 Smartcard access over an ssh connection. So it might be possible
sorry, forgot th add the link https://p11-glue.github.io/p11-glue/p11-kit/manual/remoting.html
to open the ssh connection with the ssh key, forward the PKCS#11 access to the remote host and then use a pam module in the session phase to do a pkinit with the forwarded PKCS#11. The of course means you need a certificate on the hardware token as well. What I currently do not know is if a PIN input is required of if the PIN can be somehow kept in memory of the local computer similar to what the ssh agent would do.
SSSD might be able to provide the needed pam operations during the session phase but if you want to start experimenting with forwarded PKCS#11 I think using pam_exec to call kinit with the required pkinit option would be a good start.
HTH
bye, Sumit
//Adam
From: externaly-forwarded@smhi.se externaly-forwarded@smhi.se on behalf of Winberg Adam Adam.Winberg@smhi.se Sent: 17 November 2020 08:00 To: sssd-users@lists.fedorahosted.org Subject: [SSSD-users] SSH keys and kerberos ticket
Hi,
in our environment all NFS shares are mounted with 'sec=krb5' and user homedirs are on NFS. So when users logs in via SSH they need a kerberos ticket to read their homedir. SSH with GSSAPIAuthentication would solve this, and of course user/password works as well. But for different reasons we want to restrict login to ssh keys only, with the key stored non-exportable on a hard token (smartcard/yubikey) and the public part stored in AD (accessed by using sshd config option 'AuthorizedKeysCommand /usr/bin/sss_ssh_authorizedkeys'). The problem is that the user does not get a kerberos ticket on login with this scheme, forcing them to use 'kinit' which requires password which we dont want to use.
I've read
https://bugzilla.redhat.com/show_bug.cgi?id=1017651
and
https://fedorahosted.org/freeipa/ticket/4000
The bugzilla is old but contains new, relevant input from users but no new comments from any devs - are there any new thoughts of making SSSD/sshd capable of retrieving a kerberos TGT for a user logged in with ssh keys? I understand the security concerns, but having the keys non-exportable on a hard token and storing the public part in AD/IdM should solve those issues, dont you think?
Right now we are stuck between two security principles (requiring krb auth for NFS access and using a secure ssh key setup for access) that dont play nice with each other.
Regards
Adam
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.o...
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.o...
sssd-users@lists.fedorahosted.org
-
Sumit Bose -
Winberg Adam