Support hardware keys prompts in Connect#47652
Conversation
ravicious
left a comment
ravicious
left a comment
There was a problem hiding this comment.
The happy path seems to work fine, I was testing with hardware_key_touch_and_pin. I found one edge case though which seems worth addressing.
There was a problem hiding this comment.
I found a weird edge case that I'm able to consistently reproduce:
- Log out of the cluster, remove your key and plug it back in.
- Make sure the cluster uses
hardware_key_touch_and_pin. - Provide credentials for the cluster.
- Tap the key to get through the regular MFA dialog.
- Provide the PIN to get through the next one.
- Close the PIV dialog asking you to tap the key.
At this point, the UI aborts the operation, but it looks like the key keeps blinking as if waiting for a touch. Matter of fact, if I try to log in again, when I get to the regular MFA dialog I have to tap the key twice. It seems like when the PIV touch dialog is closed, the request for a tap on tshd side is not properly canceled maybe?
FWIW, I can reproduce this with tsh (provide PIN, tap to get through "Tap any security key", then CTRL+C on "Tap your YubiKey") which indicates that it's not related to the JS side of things.
There was a problem hiding this comment.
This is possible. The problem comes from a fact that the signer.Sign interface doesn't accept a context so we can't just cancel the entire call that prompts for PIN/touch. Because of that, I had to introduce abandonableSign so at least I can abandon the call.
I thought that perhaps an option would be to close the entire PIV connection when the context is cancelled (although I'd like to avoid it) but it doesn't seem to change anything, the key still blinks for a few seconds. This may be YubiKey's behavior, where the key physcially waits for PIN/touch for some time.
There was a problem hiding this comment.
Could you capture this in an issue so that we have something to refer to when someone runs into that as well?
|
Friendly ping @Joerger |
* Add new protos for hardware key prompts * Implement hardware key prompts on the daemon side * Show prompts in the UI * `PromptHardwareKeyPINAsk` -> `PromptHardwareKeyPIN` * Improve proto docs * `PromptHardwareKeySlotOverwrite` -> `ConfirmHardwareKeySlotOverwrite` * Fix typo * Remove unnecessary `form` * Pass an enum to `AskPIN` instead of the entire message * Remove an invalid restriction of PIN/PUK to numbers only * Improve the copy (cherry picked from commit 22b5014)
* Support hardware keys prompts in Connect (#47652) * Add new protos for hardware key prompts * Implement hardware key prompts on the daemon side * Show prompts in the UI * `PromptHardwareKeyPINAsk` -> `PromptHardwareKeyPIN` * Improve proto docs * `PromptHardwareKeySlotOverwrite` -> `ConfirmHardwareKeySlotOverwrite` * Fix typo * Remove unnecessary `form` * Pass an enum to `AskPIN` instead of the entire message * Remove an invalid restriction of PIN/PUK to numbers only * Improve the copy (cherry picked from commit 22b5014) * Update generated proto files * Regenerate proto file
3 participants
Closes #30030 #17311 #34415
This is the last PR for a hardware keys support in Connect.
Since
yubikey.gonow supports custom prompts, we can pass it a one that shows modals in the Electron app.The prompts are displayed as important modals. The UX of this is not perfect, since if you have to unlock the hardware key during log-in, you will see a dialog on top of other dialog. Earlier I considered integrating these prompts with a login dialog, but that would require some significant changes on the frontend side (if there’s a login in progress the prompt should be a part of the login dialog, otherwise it should be a standalone dialog). Because of the additional complexity, I kept this out of scope.
TODO: Add hardware keys to the test plan.
Best to review commit-by-commit.
How to test it
PIV=dynamic make build/tsh(same for teleport)hardware_key_touch_and_pinto have all possible prompts).changelog: Add support for hardware keys in Teleport Connect