Hello list,

This is also something I looked at a while ago, and I effectively came to the 
same conclusion as Sumit, but with a but more nuance. Note that I never quite 
managed to implement a fix, but I'll share my thoughts here anyway.
SSH key authentication is done by sshd, and kerberos has no idea what an ssh 
key means. I thought of/found the following alternatives.
- If your home folder is on NFS, the home folder of the authenticating user is 
not available for authentication. This means the user's authorized_keys must 
live somewhere else, for example in freeipa.
- You can authenticate to kerberos using a certificate (see smartcard 
authentication), and it is possible to use the same certificate to authenticate 
to sshd, although that does require help from a freeipa wrapper 
(/usr/bin/sss_ssh_authorizedkeys). However, you need a modified version of 
ssh(d) (*not sure if it's only the sshd daemon or also the client) to be able 
to use the provided cert to get sshd to get you a kerberos ticket. This already 
exists, but I can't find it at the moment. Either way, sounds like a terrible 
idea to me.
- Have your ssh client authenticate to the kdc and get a ticket, and use that 
ticket to authenticate to sshd. This means that you have to expose your kdc to 
all your clients (i.e. the internet). Sounds like a terrible idea to me.
- Generate a kerberos service for sshd, and trust it for delegation (meaning, 
it's allowed to hand out tgts for other users, as I understand it), get a 
keytab, and then wrestle with PAM to generate tgts once sshd is happy with the 
provided ssh key. This sounds like a reasonable idea to me, but puts a lot of 
trust in sshd (even more than usual). Plus, you'd best make sure you never lose 
that keytab.
- Add pam_krb5 to the sshd authentication flow, so it asks for a password after 
ssh-key authentication to get a kerberos ticket. Probably safest, but breaks 
automatic authentication.

I hope this helps, and please let me know if you figure out something smarter ;)
Peter

________________________________________
From: Sumit Bose via FreeIPA-users <[email protected]>
Sent: Thursday, 13 February 2025 16:12
To: FreeIPA users list
Cc: Ronald Wimmer; Sumit Bose
Subject: [Freeipa-users] Re: IPA pubkey auth and NFS KRB5

Am Thu, Feb 13, 2025 at 02:24:58PM +0100 schrieb Ronald Wimmer via 
FreeIPA-users:
> I am aware of two cases here. The first one is that I do already have a TGT
> that I can delegate to the target host and some magic fetches the right NFS
> ticket for me. The second one is that I connect to the target host and enter
> a password and SSSD fetches a TGT and NFS ticket for me.
>
> Both cases allow me to access a kerberized NFS share. But what is when I use
> SSH pubkey auth (pubkey in IPA) to connect to the target host? Should I also
> get a TGT and NFS ticket to access a kerberized NFS share?

Hi,

no, pubkey authentication happens completely inside of sshd and no one
else has access to anything involved and hence cannot act upon it.

HTH

bye,
Sumit

>
> Cheers,
> Ronald
> --
> _______________________________________________
> FreeIPA-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]
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue

--
_______________________________________________
FreeIPA-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]
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue
-- 
_______________________________________________
FreeIPA-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]
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Reply via email to