Bug 1701174
| Summary: | Not able to connect to other hosts from non-localhost Cockpit login screen | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | Stef Walter <stefw> |
| Component: | cockpit | Assignee: | Martin Pitt <mpitt> |
| Status: | CLOSED ERRATA | QA Contact: | Release Test Team <release-test-team-automation> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 8.0 | CC: | sraymaek |
| Target Milestone: | rc | Keywords: | Rebase |
| Target Release: | 8.1 | Flags: | pm-rhel:
mirror+
|
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2019-11-05 22:03:23 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Stef Walter
2019-04-18 09:52:15 UTC
I tried this on our fedora-30 and rhel-8-0 cockpit test VMs, and can confirm that on both I get "Refusing to connect. Host is unknown". But on my Fedora 30 laptop, with the exact same packages, I get "The authenticity of host '192.168.2.106:22' can't be established. Do you want to proceed this time? SHA256 Fingerprint (ssh-ed25519):", as expected. So this seems less about Fedora vs. RHEL (i. e. about different libssh versions), and more about some specific circumstances how these get run. I'll investigate this more closely. In which environment were you running this? I tried "cockpit-bridge --interact=---" on a remote host on both my laptop (where it works) and the fedora-30 test VM (where it fails), and in both cases it looks the same:
(cockpit-ssh:21520): cockpit-ssh-DEBUG: 09:32:23.047: cockpit-ssh 192.168.2.106: host not known in any local file, asking sssd
(cockpit-ssh:21520): cockpit-ssh-DEBUG: 09:32:23.049: cockpit-ssh 192.168.2.106: Failed to run sss_ssh_knownhostsproxy: Failed to execute child process ?sss_ssh_knownhostsproxy? (No such file or directory)
(cockpit-ssh:21520): cockpit-ssh-DEBUG: 09:32:23.050: cockpit-ssh 192.168.2.106: using known hosts file (null)
(cockpit-ssh:21520): cockpit-ssh-DEBUG: 09:32:23.096: cockpit-ssh 192.168.2.106: connected
{"command":"authorize", [...],"message":"The authenticity of host '192.168.2.106:22' can't be established. Do you want to proceed this time?","default":"SHA256:AIJoCTtgu/0t0uYrHks9L4CfWrd5IBAcOWqK9Qk3JHA","host-key":"192.168.2.106 ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIB3vmfHvYyCruT6E9NQZleFCKx7lPN/lpLlINREOCZd/\n","echo":true}
But (only) in the non-working case, I see this in the journal:
cockpit-ssh 172.27.0.15: refusing to connect to unknown host: 172.27.0.15:22
Indeed the difference between these two scenarios is that data->ssh_options->connect_to_unknown_hosts is 1 locally (working case) and 0 in the VM (broken case). It turns out that cockpit-ssh's $COCKPIT_REMOTE_PEER value is bogus: On my laptop it's ::1, while in my VM it's 172.27.0.2, both of which are the IP addresses of the cockpit-ws instance, *not* the address of the remote ssh host to connect to. That explains the symptom, as get_connect_to_unknown_hosts() allows connections to localhost with unknown host keys.
This actually seems like a really ancient bug, from as far back as https://github.com/cockpit-project/cockpit/commit/f087f5ca3be097 . $COCKPIT_REMOTE_PEER is really confusing -- cockpit-ws sets it to the connecting user from *its* point of view, but cockpit-ssh tries to interpret it as the IP to connect to with ssh. I just wonder how our tests are missing this -- check-multi-machine covers both direct URL login (where unknown hosts should fail) and "Connect to:" login page logins, where they should prompt. They use the browser on the outside on the redirected port 9090 (i. e. something like 127.0.0.2:9091) just as I do interactively. Stef, Sanne: In https://github.com/martinpitt/cockpit/commits/ssh-remote-peer I fixed the mis-interpretation of COCKPIT_REMOTE_PEER, so that on the login page unknown hosts are now consistently rejected. Adding unknown servers on the Dashboard prompts. As COCKPIT_SSH_CONNECT_TO_UNKNOWN_HOSTS isn't set anywhere except /usr/share/cockpit/ssh/manifest.json in the "session: private" case, I suppose the Dashboard takes that code path. This connection to private sessions isn't quite obvious, and feels rather hackish - it should at least be documented better in doc/protocol.md. Stef, could you please explain the background there, how private sessions relate to trustworthiness of unknown remote ssh servers? To fix that properly, I think login.js needs to tell apart the "direct URL" case (like http://localhost:9999/=192.168.2.106), which should always fail for unknown hosts, from the "remote server specified in the Connect to: field", which should prompt. In the latter case, COCKPIT_SSH_CONNECT_TO_UNKNOWN_HOSTS needs to be passed. Does that make sense? Is there a less complicated way to do that? > I just wonder how our tests are missing this
Got it -- testDirectLogin() writes allowUnknown to cockpit.conf for the direct URL login check and then forgets to remove it again for the "Connect to:" test.
> login.js needs to tell apart the "direct URL" case from the "remote server specified in the Connect to: field"
This is rather hard -- in both cases, the URL path is something like /cockpit+=10.111.113.2/login and the application is something like "cockpit+=10.111.113.2", so cockpitauth.c cannot tell these apart. So it seems it needs to become a hack in login.js, and be passed through the protocol as a new option? Stef, any idea about that one?
I now have a fix which isn't *too* bad, I think: https://github.com/cockpit-project/cockpit/pull/11736 Fix landed upstream, will be in 194 Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2019:3518 |