shell: Redesign untrusted "add host" dialog #19409
Conversation
martinpitt
added
needsdesign
no-test
|
If possible, I'd also like to trim the alert text a bit, to fit on one line (at least in English). Perhaps:
? |
|
This modal is way overloaded. It's not clear what's going on, what's important, what someone needs to do, etc. I'm trying to figure this out in a mockup right now. As for the new part of this PR, the security issue: It's not error, nor is it an alert (of something that's been done already). Opting in is clicking the button; it doesn't need to have an "unbreak the UI" toggle. Still, this modal was already too complex before adding anything else, and it's extremely overloaded now. I hope to finish up a suggestion with a mockup soon and I'll share it here when I have it. |
|
Thanks @garrett ! I might add,in practice nobody will actually (be able to) do this elaborate key comparison exercise. In larger environments there are better ways to distribute known host keys (via FreeIPA or SSH CA), and if not: if you never connected to a machine, you will not have a "secret trustworthy side channel" to do the procedure outlined in the dialog. In practice, everyone uses "trust on first use" (TOFU) with SSH. |
|
@martinpitt: Ah, that's what I thought, but wasn't sure. Additionally, corps should really be using CA with SSH certs, but in practice, few do. https://smallstep.com/blog/use-ssh-certificates/ I guess I'll redesign the modal to be even simpler now! |
|
This isn't done, but I thuoght I should share what I have before the upcoming long weekend. I'd like to get feedback. HOSTNAME is the actual hostname or IP address.
I don't have the "View details" popover for the details for the session stuff yet. We might want to have a popover for "certificate authority" and we might want to ditch the extended sharing info. What do you think so far? |
|
Oh, the warning text at the bottom has a typo. I revised it a few times and accidentally left it in that state. 😅 |
|
Nice, thanks @garrett ! I like the decomposition/expanders. I'm less sure about the "not using certificate authority" -- that's one way to assert a known host, but (unfortunately) more of a fringe case, and confusing for casual users. I like the original "you are connecting to hostname for the first time", as when you see it, it's exactly right, and doesn't induce fear. |
This comment was marked as outdated.
This comment was marked as outdated.
martinpitt
force-pushed
the
untrusted-hosts
branch
from
88fdeac
to
6bfc2c1
Compare
martinpitt
changed the title
This comment was marked as resolved.
This comment was marked as resolved.
|
Thanks @garrett and @allisonkarlitskaya ! I updated the warning string, and put current screenshots into the description. Triggering f38 tests to see what I need to adjust. |
martinpitt
force-pushed
the
untrusted-hosts
branch
from
6bfc2c1
to
d8bb31b
Compare
martinpitt
removed
needsdesign
no-test
All our currently supported releases have an `ssh-keyken` version that supports `-E`.
Remote machines can send malicious cockpit pages which do iframe traversal or use the `host` channel option to run arbitrary code on all other currently connected Cockpit sessions. Isolating cockpit sessions from different hosts from one another is difficult, and properly implementing this will take a while (if it's possible at all): https://issues.redhat.com/browse/COCKPIT-870 Until this happens, warn users about that in the "unknown host" shell dialog. Also hide the "verify fingerprint" recipe behind an expander. In practice, most users do "Trust On First Use" anyway, as validating a FP properly is too hard. This makes the dialog less overwhelming and also puts more emphasis on the "trust" aspect. Add a check to TestMultiMachine.testTroubleshooting which actually runs the generated validation command and ensures that the shown fingerprint matches. Related to https://issues.redhat.com/browse/COCKPIT-870
martinpitt
force-pushed
the
untrusted-hosts
branch
from
d8bb31b
to
2287fc8
Compare
|
This is now ready. I did the final tweaks discussed with @garrett (drop the period in the alert), adjusted tests, and cleaned them up a bit while I was at it. |
| @@ -479,18 +484,24 @@ class HostKey extends React.Component { | |||
| <p>{cockpit.format(_("To verify a fingerprint, run the following on $0 while physically sitting at the machine or through a trusted network:"), this.props.host)}</p> | |||
| <ClipboardCopy isReadOnly hoverTip={_("Copy")} clickTip={_("Copied")} className="hostkey-verify-help-cmds pf-v5-u-font-family-monospace">ssh-keyscan -t {key_type} localhost | ssh-keygen -lf -</ClipboardCopy> | |||
| <p>{_("The resulting fingerprint is fine to share via public methods, including email.")}</p> | |||
| <p>{_("If the fingerprint matches, click 'Accept key and connect'. Otherwise, do not connect and contact your administrator.")}</p> | |||
| <p>{_("If the fingerprint matches, click 'Trust and add host'. Otherwise, do not connect and contact your administrator.")}</p> | |||
There was a problem hiding this comment.
This added line is not executed by any test. Details
Remote machines can send malicious cockpit pages which do iframe traversal or use the
hostchannel option to run arbitrary code on all other currently connected Cockpit sessions.Isolating cockpit sessions from different hosts from one another is difficult, and properly implementing this will take a while (if it's possible at all): https://issues.redhat.com/browse/COCKPIT-870
Until this happens, warn users about that in the "unknown host" shell dialog.
Also hide the "verify fingerprint" recipe behind an expander. In practice, most users do "Trust On First Use" anyway, as validating a FP properly is too hard. This makes the dialog less overwhelming and also puts more emphasis on the "trust" aspect.
Add a check to TestMultiMachine.testTroubleshooting which actually runs the generated validation command and ensures that the shown fingerprint matches.
Initial dialog, FP validation collapsed by default:
FP validation expanded:
FP popover: