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