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(a)smhi.se <externaly-forwarded(a)smhi.se> on behalf of
Winberg Adam <Adam.Winberg(a)smhi.se>
> 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
>
>
> _______________________________________________
> 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
> List Archives:
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahoste...
_______________________________________________
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
List Archives:
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahoste...