Shell: Extra warnings when connecting to remote hosts

[mvollmer]

Shell: Extra warnings when connecting to remote hosts

Connecting to multiple hosts in a single Cockpit session allows all these hosts to access each other freely. Eventually Cockpit will not allow multiple connections, but in the mean time, we want to educate people better.

This warning can be disabled by including the following in /etc/cockpit/cockpit.conf:

[Session] 
WarnBeforeConnecting=false

---

Demo: https://youtu.be/Un6k3DiukOg

[garrett]

I was thinking of something more like this:

Then we can succinctly explain what can happen, provide a link with more information, and say this will show up once per session on the very first connection to any remote machine (instead of a "don't remind me"). If accepted, it would not show up again until the next Cockpit session.

The external page would explain it a little more in depth and mention the config file options, including:

1. Being able to toggle the host connection feature on and off completely
2. Being able to toggle off this warning message (which only matters if remote host connection is on)

Marius said this could be a three-state option, which I agree with:

1. Off (default for RHEL/CentOS)
2. On (default for non-RHEL/CentOS)
3. On without warnings (never default; an override to prevent the connection message that must be manually set)

This would prevent someone from connecting to a host machine without knowing the ramifications, but also allow them to work more-or-less how they currently do, with a workaround to skip the warning in some environments.

If we are indeed going to outright remove this feature, then we could even rephrase the modal and be explicit about the timeline in the external page, something like this:

These mockups are just examples of what we could do instead, and we'd want to revise the text and plan for the actual version where it would be removed.

[mvollmer]

@garrett, could you check https://www.youtube.com/watch?v=wL4VyE9tUb8 and tell me whether this goes in the right direction? Then I can work on making this nice and robust.

[garrett]

@mvollmer: I'm watching this video and wondering: Why is it different form the mockups and discussion we talked about? (See above comment https://github.com/cockpit-project/cockpit/pull/20826#issuecomment-2263153534)

[mvollmer]

I'm watching this video and wondering: Why is it different form the mockups and discussion we talked about?

@garrett, the difference I see is that the dialog is shown more often than what you described. Correct? The warning should be shown only for the very first connection in the session, right? So maximum number of times we show the warning per session is 1. (And reloading doesn't start a new session.)

What do you think of immediately opening the connection dialog when the URL already points to a remote machine when you login to the Cockpit session?

Any opinions about the "Not connected" placeholder page that you see when cancelling the connection dialog in that case? Should we keep it? Redesign it?

[mvollmer]

There are lots more opportunities for cleanup, but I think this is fine for now. The next step would probably be to turn the whole shell into a React component and move the trigger_connection_flow thing into the top component so that it can be cleanly triggered from anywhere in the shell.

[mvollmer]

However: After I added a new host, I got the connect warning dialog and then the key dialog, all as expected. However, it didn't switch to that remote host. Instead, it stayed on the original host and the switcher persisted.

Yes, that's the current behavior of the shell. I have included #21004 here now to jump to a newly added host immediately.

[garrett]

We need to create a document about this, and make sure the link is correct:

https://cockpit-project.org/guide/latest/multi-host.html

Also, what do we do about RHEL? We probably don't want to link to Cockpit from RHEL.

I did get the login prompt after adding, as it seems like it does try to connect now (which makes sense), but then I got an error. Since it's Debian stable on Arm and I'm connecting from Fedora 41 on x86, it's not going to beibooot anyway (except from Cockpit Client or the container). It's almost guaranteed to not be related to this PR, but we should address it in a different PR:

The bug is that the close "button" is not a button, but should be. But it's not related to this PR. I'll file an issue.

---

Summary:

1. PR looks functionally good
2. We need to write about the warning and how to opt-out to disable it
3. We need to make sure the link is correct
4. ??? Something, something RHEL ??? (We need to probably not link to Cockpit.org from RHEL Web Console)

[mvollmer]

We need to create a document about this, and make sure the link is correct:

The document is part of this PR: https://github.com/cockpit-project/cockpit/blob/3d812b1783c63a2395d10d7a741052a9b25bbe99/doc/guide/multi-host.xml

It will appear at the URL once we make a release after this PR is merged.

Also, what do we do about RHEL? We probably don't want to link to Cockpit from RHEL.

I don't know... Can we do this as a follow?

[garrett]

I don't know... Can we do this as a follow?

Sure, as long as we immediately work on it. Thanks.

[martinpitt]

This failure may be potential fallout, but the other three failures are known flakes. Round of retries for comparison.

[martinpitt]

@mvollmer Still the same failure :cry:

[mvollmer]

@mvollmer Still the same failure 😢

Passes locally for me, hmmm.

[mvollmer]

@mvollmer Still the same failure 😢

It's very likely the PerSourcePenalty thing:

sshd[799]: drop connection #0 from [10.111.113.1]:52904 on [10.111.113.2]:22 penalty: failed authentication

fedora-41 has openssh 9.8, which implements this and also seems to have it enabled:

# sshd -T | grep -i PerSource
persourcepenaltyexemptlist none
persourcemaxstartups none
persourcenetblocksize 32:128
persourcepenalties crash:90 authfail:5 noauth:1 grace-exceeded:20 max:600 min:15 max-sources4:65536 max-sources6:65536 overflow:permissive overflow6:permissive

(and that's how I slide seamlessly into the pilot seat... :-)

[martinpitt]

https://github.com/cockpit-project/bots/pull/7100 landed, so retrying the failed f41.

[martinpitt]

@mvollmer meh -- I retried this DarkThemeSwitcher failure three times now, it won't budge. I haven't seen this recently in other PRs -- may this actually be broken now?

[mvollmer]

@mvollmer meh -- I retried this DarkThemeSwitcher failure three times now, it won't budge. I haven't seen this recently in other PRs -- may this actually be broken now?

Yep, on it.

[mvollmer]

@mvollmer meh -- I retried this DarkThemeSwitcher failure three times now, it won't budge. I haven't seen this recently in other PRs -- may this actually be broken now?

Yep, on it.

sshd[1118]: drop connection #0 from [127.0.0.1]:37922 on [127.0.0.1]:22 penalty: failed authentication

Hmm...

[martinpitt]

@mvollmer ah! Fedora CoreOS also recently moved to 41.

[martinpitt]

I see that flake in https://cockpit-logs.us-east-1.linodeobjects.com/pull-21268-5fa6bed5-20241115-083027-fedora-coreos-other/log.html as well, so it's indeed unrelated here. Feel free to just unconflict this (but note that #21239 also changes pixel tests, and will go in as soon as its fcos test passes), and ignore that flake here (it'll need a bots PR anyway)

[mvollmer]

Feel free to just unconflict this

Done.