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:
But this requires that the user has a valid TGT to start with, so the question can still
be of interest for others.
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.
From: externaly-forwarded(a)smhi.se <externaly-forwarded(a)smhi.se> on behalf of
Winberg Adam <Adam.Winberg(a)smhi.se>
Sent: 17 November 2020 08:00
Subject: [SSSD-users] SSH keys and kerberos ticket
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.
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.
sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
To unsubscribe send an email to sssd-users-leave(a)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