[SSSD-users] Re: SSH keys and kerberos ticket

[Winberg 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(a)smhi.se <externaly-forwarded(a)smhi.se&gt; on behalf of Winberg
Adam <Adam.Winberg(a)smhi.se&gt;
Sent: 17 November 2020 08:00
To: sssd-users(a)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