Ticket was cloned from Red Hat Bugzilla (product Red Hat Enterprise Linux 6): Bug 1017651
Description of problem: Logging into a machine enrolled as an IPA client does not automatically create a kerberos ticket. Version-Release number of selected component (if applicable): ipa-server-3.0.0-26.el6_4.4.x86_64 ipa-client-3.0.0-26.el6_4.4.x86_64 How reproducible: Always. Steps to Reproduce: [max@otlonlin050:~] $ ssh linux01 [max@linux01 ~]$ klist Actual results: [max@linux01 ~]$ klist klist: No credentials cache found (ticket cache FILE:/tmp/krb5cc_1637600006) Expected results: $ klist Ticket cache: FILE:/tmp/krb5cc_1637600006 Default principal: max@XYZ.COM Valid starting Expires Service principal 10/10/13 09:46:12 10/11/13 09:46:09 krbtgt/XYZ.COM@XYZ.COM Additional info: I have to manually invoke kinit and provide my password after the ssh login. All ssh users are authenticated using IPA. From sshd_config: AuthorizedKeysCommand /usr/bin/sss_ssh_authorizedkeys
This is an unsolvable problem.
The issue is that with SSH keys you are completely deferring authentication to the target machine and the KDC is not involved in any way. In order to release a TGT for a user the KDC needs proof of knowledge of the user's long term secret. The target machine does not have that knowledge, because the user logged in via SSH keys not username/password, so it has no way to ask the KDC for a user TGT.
If it is desired to have a kerberos TGT on the target machine but log in without providing the password then the only option is to use GSSAPI authentication with SSH and the -K switch to forward the user TGT from the client machine to the target machine.
I agree that "authenticated by SSH on x.example.org" is a virtually meaningless statement. So, how does SSH forward proof of identity to something more trustworthy, like IPA? (and get rewarded by a TGT for its troubles?)
For the case where SSH keys are stored in IPA, at some point in time the target machine must consult IPA to lookup the authorized keys. Call this partially deferring the authentication. If the target machine instead patched the connecting party thru to IPA, IPA could then challenge the connecting party to ensure they have the private key. Once IPA is convinced of the other person's identity, it could then command the KDC to mint a ticket via the S4U[blah] specs, which it could then return. Or IPA could sign a proxy certificate for sshd/sssd on the target machine to use in a subsequent PKINIT AS exchange via established protocols.
I assume the sticky part is that the publickey authentication has fewer hooks into things like PAM and sssd. It's all hardwired inside the openssh implementation, so "publickey" is the one authentication method which is locked into meaning "authenticated by SSH on x.example.org".
To say this is unsolvable is somewhat harsh. Solving it doesn't even change RFC 4252. The sshd server needs to defer the check that the "key is a valid authenticator for the user" to the domain controller. This is a stronger confidence in the authentication, and if achievable should be awarded a stronger token in return (TGT).
The obvious use case for this would be to store the public key of your smart card in IPA, so that PuttySC/PuttyCAC/etc can help you not send your long term secret over the wire. (Or make it so you can disable passwords altogether.) Or it can be a limited, convenience-oriented two-factor auth: you have possession of the device on which the private key resides, and you're using credentials with access rights to that key.
If ssh pub keys granted TGT through IPA it would help use reduce the attack surface on home directories and give us more migration strategies like moving to CIFS.
Currently we need to use mount sec=sys. This is risky because I work for an university where CS students like to 'explore/pentest'.
I wonder whether the P-box work that Simo is looking into now can be leveraged in this case too. The concern is that the solution will allow the system to impersonate any user to KDC. But it might not be that bad since Kerberos is not used at all at the moment but I can't say whether introducing Kerberos with S4U2Self + S4U2Proxy via GSSproxy on the system will make it more or less secure. So the solution might be for the SSH agent to grow a call to GSSproxy. Needs more thought.
After reviewing the SSHD config it seems something will need to be added that allows generic external tools, in this case FreeIPA to independently challenge the client. On a successful challenge FreeIPA would return the {PUB_KEY, TGT}. SSHD would then use the PUB_KEY if its an allowed encryption type and set the TGT for the user.
Perhaps some of the OpenSSH developers can chime in.
I am not an expert but I do not think how it should be. First SSSD will return public key to SSH as it does now. Once SSH is OK with the public key and finished the authentication SSH should initiate interaction with GSSproxy in a similar way P-box would work. I do not know what is the exact hook in SSH to do it but the main point is that it should be done after the pub key authentication complete. TGT just can't be returned before (theoretically it can but from security POV I do not think it is a good idea).
dev_mtg: Future Releases
Metadata Update from @mkosek: - Issue assigned to someone - Issue set to the milestone: Future Releases
Thank you taking time to submit this request for FreeIPA. Unfortunately this bug was not given priority and the team lacks the capacity to work on it at this time.
Given that we are unable to fulfil this request I am closing the issue as wontfix. To request re-consideration of this decision please reopen this issue and provide additional technical details about its importance to you.
Metadata Update from @rcritten: - Issue close_status updated to: wontfix - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.