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: [email protected] <[email protected]> on behalf > > of Winberg Adam <[email protected]> > > Sent: 17 November 2020 08:00 > > To: [email protected] > > 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 -- [email protected] > > To unsubscribe send an email to [email protected] > > 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/[email protected] > _______________________________________________ > sssd-users mailing list -- [email protected] > To unsubscribe send an email to [email protected] > 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/[email protected] _______________________________________________ sssd-users mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected]
