Learn more about these different git repos.
Other Git URLs
I've got a host, foo.ipa.example.com and I've added a Kerberos Principal Alias host/foo.local for it.
foo.ipa.example.com
host/foo.local
Although ssh foo.local now lets me authenticate with Kerberos, I'm still prompted to confirm the SSH host key.
ssh foo.local
It would be nice if the SSH responder was able to look up hosts by any aliases they may have.
Hi,
the sss_ssh_knownhostsproxy utility should try to canonicalize the given name. How do the related DNS records for foo.ipa.example.com and foo.local look like?
sss_ssh_knownhostsproxy
foo.local
bye, Sumit
A little more detail: I had two laptops on a network that wasn't mine, and was trying to see if I could SSH from one to another using Kerberos for authentication.
So in this scenario the reverse zone isn't controlled by FreeIPA, so PTR records can't be relied upon. And on this particular network, the ISP (Sky) intercept all DNS traffic and drop nsupdate's traffic, so you can't even look up foo.ipa.example.com.
If this is simply not a supported scenario then fair enough. But that said, I don't see why it's necessary to lean on the DNS at all in this scenario: there's a host/foo.local principal available, and foo.local is resolvable via mDNS, so things should Just Work...
Next time I'm in this situation I can attach debug logs for the ssh responder if this is in fact expected to work...
thanks for the explanation. I would say that this setup is currently not supported.
As said, currently it is expected that sss_ssh_knownhostsproxy can canonicalized the name with the help of DNS and then asks the ssh responder with the canonical name. As a result the ssh responder and the backend only search in places where the canonical name is stored and do not try try lookup aliases e.g. in the krbPrincipalName attribute where the alias name can be found in your case.
krbPrincipalName
Metadata Update from @thalman: - Issue tagged with: Canditate to close
Thank you for taking time to submit this request for SSSD. Unfortunately this issue was not given priority and the team lacks the capacity to work on it at this time.
Given that we are unable to fulfill this request I am closing the issue as wontfix.
If the issue still persist on recent SSSD you can request re-consideration of this decision by reopening this issue. Please provide additional technical details about its importance to you.
Thank you for understanding.
Metadata Update from @pbrezina: - Issue close_status updated to: wontfix - Issue status updated to: Closed (was: Open)
SSSD is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in SSSD's github repository.
This issue has been cloned to Github and is available here: - https://github.com/SSSD/sssd/issues/5078
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Login to comment on this ticket.