Can't really speak to the point of the guy you're replying to, but the FreeIPA implementation via SSSD does more than just Kerberos tickets. Actually, I think the Kerberos based stuff as it relates to SSH is GSSAPI as part of sshd itself and has little to do with sssd, though I could be wrong.
That said...
If I'm remembering things correctly (and it's been a looong while since I've played with this), FreeIPA's client configures sshd with an AuthorizedKeysCommand that executes a program that queries sssd for the list of authorized keys for a given user. Sssd then uses a plugin to query the LDAP server @ FreeIPA to get the list of keys.
There's also SSHFP (I think) records in DNS if you're using FreeIPA's DNS servers. These provide the host keys for servers for your ssh client to check against. Not sure if that's integrated into ssh itself or something else -- I can't remember how it's implemented offhand -- but it's fairly nifty since you never see the TOFU prompt (or it would be if DNS was actually secure, anyway).
Yes, FreeIPA is Kerberos+LDAP+X.509 CA, and GSSAPI is in OpenSSH (normally with the key exchange patch). SSSD is a local mechanism, not network authentication. I mentioned authorized keys distribution mechanisms elsewhere, but I was thinking authentication (c.f. OIDC), not authorization.
Yes, but its authN components only act locally, and PAM is optional for sshd. It can/does call out to network services like Kerberos/LDAP given a password, of course, but I was thinking of network authN connected directly with OIDC somehow, for which I don't know a mechanism in vanilla OpenSSH. (I don't know what Authentik does for this -- I could imagine it's behind the scenes somehow.) I should probably look it up sometime.
My understanding is since it's an agent running on the target, possibilities will be quite extensive. But it is relatively new and there is no stable release of it yet.
Life is easier if you can use Kerberos SSO, i.e. GSSAPIAuthentication in OpenSSH. (If we're talking certificates, presumably it is OpenSSH, or does anything else implement them?)
I don't want to have to get a special purpose credential when I have a TGT which can work generally, and is at least required for secure remote filesystem access.
You have to manage extra infrastructure for certificates and, as a user, have the friction of firing up a JavaScript-enabled web browser via an additional tool, assuming "real IdP" means using OIDC. Unfortunately that flow is actually needed for remote systems and something like Edugain federation, since Moonshot/IETF ABFAB failed, but at least Shibboleth can use the TGT, and it's not the Globus horror.
Every serious shop of any real size is already managing an OIDC IdP (you need one for whatever SAAS apps your team is using along with any internal web applications you're using). Why not just link it to something that can issue short-lived SSH certificates? That's also the cleanest way to get strong multifactor auth for SSH (certificates issued only through an OIDC progress minted with MFA requirements).
Setting up Kerberos in 2026 feels somewhat close to malpractice to me.
I'm happy for anyone who doesn't have MS Windows/Active Directory -- so Kerberos -- in their organization, but I'd need (Free)IPA or similar for user/access management anyway. Certificates are an extra layer of SSH-specific complexity, which concerns me for security even if it doesn't involve some third party. MFA is needed once a day, say, for SSO to all Kerberized services. [As I understand it, "managing an OIDC IdP" includes shipping the contents of Active Directory to Entra, heaven help us.]
> Setting up Kerberos in 2026 feels somewhat close to malpractice to me.
Microsoft (if that means anything, but they've done good work) and Red Hat obviously disagree, along with decades' experience. It is malpractice not to secure NFS mounts (and other network filesystems with sensitive data), and that means Kerberos.
I wish that (still) worked reliably, but it can unfortunately get one into trouble with some compilers and some optimization modes that assume that NaNs are undefined behavior.
> I had a Fairphone 3, and after 5 years, /e/OS was outdated by 4 years w.r.t. the manufacturer updates
Mine is running /e/ and reporting Android 13, which appears to be the last one Fairphone support. /e/ said it was too difficult to support 14 with the kernel involved. It's had continual security updates apart from the Android version.
Edit: Murena make it clear which phones are officially supported and which have "community" support.
> Mine is running /e/ and reporting Android 13, which appears to be the last one Fairphone support.
This is not the manufacturer updates. I was talking about the manufacturer updates. I just checked and someone complained a few months ago and they updated them. Before that, they had not been updated in years on /e/OS, but they were up-to-date on Stock Android.
> Edit: Murena make it clear which phones are officially supported and which have "community" support.
I bought a phone to Murena, advertised by Murena, through Murena. It really felt like it would be officially supported, otherwise they should have made it clear that they advertise and sell something that they won't support, wouldn't you say? My feeling is that they just stopped supporting it after a while.
Also I would assume that "supported" means that it receives both the LineageOS updates and the manufacturer updates. Apparently they have a different definition of "supported" (which is fine, maybe it's just "we will continue sending you our own updates"). It's just that in my book, if I get more security updates with the Stock Android than with /e/OS, then Stock Android is more secure.
> It's had continual security updates apart from the Android version.
Nope, it doesn't receive most privacy and security patches. Users are being heavily misled about what's provided. First of all, the kernel is nearly entirely not being updated which is a massive portion of the privacy and security patches. Murena's devices have poor privacy and atrocious security including due to the failure to properly provide basic privacy/security patches. Their claims about what they provide need to be distinguished from what is actually provided. /e/ updates the patch level regularly to claim they provide the security patch backports but that doesn't mean they actually provided all of them. It's an arbitrary value and they don't set it accurately.
Fairphone 3 uses the end-of-life Linux 4.9 branch, Fairphone 4 use the end-of-life Linux 4.19 branch and Fairphone 5 uses the end-of-life 5.4 branch. Each was largely not receiving the upstream LTS updates while they were still provided but now they're not provided. An OS that's not receiving basic kernel updates is definitely not receiving security patches anymore, but they were largely never providing these updates in the first place long before the kernel branch or devices were considered end-of-life.
Similar to iOS and other operating systems, Android only backports a subset of privacy and security patches to older Android branches. Only Android 16 QPR2 has the full set of Android privacy and security patches. You aren't receiving all of the standard Android privacy and security patches if you're not on Android 16 QPR2. Many of the patches are also treated as optional and deferred as being mandatory far into the future. It's also worth noting the dates are misleading. Android's March 2026 security backported have been finalized for a while and up to August 2026 are available to ship by OEMs already but a lot more will be added to June 2026. February 2026 Android security patches are the latest with a public bulletin but not the latest available to ship.
Fairphone and especially /e/ also have very incomplete patches for firmware and drivers. /e/ also has major issues patching other components including the browser engine used by the OS for the WebView.
Indeed. The first dedicated light -- for various values of "light" -- source[1] repurposed the tunnel and various bits and techniques from the particle physics accelerator it replaced, and on which parasitic "light" measurements were made previously. See also [2].
reply