As an alternative to an OTP allow client enrollment using a SSH key pair.
The process to OTP would be pretty similar. The host is pre-added and a public key added to the host either in the same step or a subsequent one.
The client authenticates <waves hands> uses the private component of the SSH key for identity and if successful, enrollment continues.
The public key is removed from the host entry upon successful enrollment.
This is an idea we're investigating in OpenStack to allow new VMs to enroll against an IPA master without having to invent a way to inject an OTP into the VM. There is already a mechanism for injecting SSH keys.
My thinking about the hand-wavy part is that a SSH private key is just an RSA key which can sign small amounts of data. We sign something using the RSA key, something like:
$ openssl rsautl -in /path/to/some_data -out /path/to/signed -inkey ~/.ssh/id_rsa -sign -keyform PEM
We then transmit the file signed to IPA in ipa-join and the server would verify the signed data. The verify would happen inside the ipa-enrollment plugin but I think we can use raw NSS calls to validate the signature.
We wouldn't be storing the SSH public key in this case but the RSA public key generated from the RSA private key:
openssl rsa -in ~/.ssh/id_rsa -outform PEM -pubout -out pubkey.pem
An open question is what data would be signed. We can probably get away with something predictable since this is still a one-time key.
Interesting idea.
I found that OpenStack's keygen can also generate x509 certs though I haven't played with it at all. I don't know if those can be injected into a node or not but that would eliminate the need to do gymnastics with the ssh key.
I chatted with Simo about this and we came up with a far simpler solution.
All we really need is proof-of-possession. Any key we stick into an Openstack host is suspect to me as some portion of that key will be visible to Openstack admins.
So any key we use carries the same level of risk.
The idea goes like this:
Keeping this open as a placeholder for now but I don't think changes will be needed in IPA at this point.
Metadata Update from @rcritten: - Issue assigned to someone - Issue set to the milestone: Tickets Deferred
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.