Skip to content

massive Peer rework, based on FernyTransport#19668

Closed
allisonkarlitskaya wants to merge 8 commits intocockpit-project:mainfrom
allisonkarlitskaya:ferny-transport
Closed

massive Peer rework, based on FernyTransport#19668
allisonkarlitskaya wants to merge 8 commits intocockpit-project:mainfrom
allisonkarlitskaya:ferny-transport

Conversation

@allisonkarlitskaya
Copy link
Member

@allisonkarlitskaya allisonkarlitskaya commented Nov 29, 2023 •
edited by martinpitt
Loading

github-advanced-security[bot]
github-advanced-security bot found potential problems Nov 29, 2023
View reviewed changes
@martinpitt martinpitt mentioned this pull request Dec 1, 2023
Merged
@allisonkarlitskaya allisonkarlitskaya force-pushed the ferny-transport branch 2 times, most recently from 2965bb2 to dc9cd0e Compare December 5, 2023 11:07
@martinpitt

This comment was marked as resolved.

Sign in to view
@allisonkarlitskaya allisonkarlitskaya force-pushed the ferny-transport branch 3 times, most recently from 8efcb70 to 5eae275 Compare December 6, 2023 12:52
github-advanced-security[bot]
github-advanced-security bot found potential problems Dec 6, 2023
View reviewed changes
@allisonkarlitskaya
Copy link
Member Author

allisonkarlitskaya commented Dec 6, 2023 •
edited
Loading

The permission denied error in the superuser case is annoying: that's the sound of the kill() syscall failing to reap the bridge running as root...

That's python/cpython#112800 but we're going to need a workaround...

@allisonkarlitskaya

This comment was marked as resolved.

Sign in to view
@martinpitt

This comment was marked as resolved.

Sign in to view
@allisonkarlitskaya allisonkarlitskaya force-pushed the ferny-transport branch 2 times, most recently from 09a5c4d to dc4ed95 Compare December 8, 2023 07:59
github-advanced-security[bot]
github-advanced-security bot found potential problems Dec 8, 2023
View reviewed changes
@martinpitt

This comment was marked as resolved.

Sign in to view
@allisonkarlitskaya
Copy link
Member Author

allisonkarlitskaya commented Dec 8, 2023

Looking at TestReverseProxy.testNginxNoTLS. It starts ws with --local-session=cockpit-bridge, but that bridge crashes right away:

Looking at the polkit code, and thinking about the error message, it's worth noting:

            self.subject = ('unix-session', {'session-id': Variant(os.environ['XDG_SESSION_ID'], 's')})

So clearly it's the not-a-real-session spawning of the bridge that's the issue here, which means that this problem is specific to this testcase.

That being said, there's nothing wrong with robustifying the code a bit there. There may be other reasons that polkit isn't going to want us to become an agent...

@allisonkarlitskaya allisonkarlitskaya force-pushed the ferny-transport branch 4 times, most recently from 6698519 to 3d568bf Compare December 11, 2023 14:53
@allisonkarlitskaya
Copy link
Member Author

allisonkarlitskaya commented Dec 11, 2023

Okay, so most stuff is getting under control by now.

A large part of the remaining problem is that the NumberOfPasswordPrompts SSH option doesn't do what its name suggests: it also controls the number of time that passphrases are prompted for, and setting it to zero effectively disables the use of locked keys.

I could add yet another option for dealing with that, but I start to wonder if maybe it's time to draw a clearer line in the sand between "interactive" and "non-interactive" uses of cockpit-beiboot.

The non-interactive case would immediately prompt for the password on startup using the * authorize message and never send authorize messages again after that. Any other place where an askpass prompt arrived would effectively be fatal. The interactive mode wouldn't prompt on startup, but would behave more or less the same as Cockpit Client expects.

I'll roll this over in my head a bit. Pending a reasonable solution there and resolution of the situation about how to run cockpit.beiboot from inside the beipack this is starting to look promising, though...

@martinpitt martinpitt mentioned this pull request Dec 12, 2023
Closed
@allisonkarlitskaya allisonkarlitskaya force-pushed the ferny-transport branch 2 times, most recently from 075c65b to e8d01ca Compare December 15, 2023 08:30
github-advanced-security[bot]
github-advanced-security bot found potential problems Dec 15, 2023
View reviewed changes
src/cockpit/beiboot.py
import socket
from pathlib import Path
from typing import Dict, Iterable, Optional, Sequence
from typing import Iterable, NamedTuple, Sequence

Check notice

Code scanning / CodeQL

Unused import

Import of 'Sequence' is not used.
martinpitt added a commit to martinpitt/cockpit that referenced this pull request Jun 27, 2024
@martinpitt
pybridge: Handle ssh host key prompts in beiboot
b00fc26 
Stop treating host key prompts as generic conversation messages. We want
the UI to handle them properly, with some verbiage/buttons and the
recipe for validating host keys, instead of letting the user type "yes".
The login page recognizes these through the presence of the `host-key`
authorize field (and irritatingly, an extra `default` field with the
actual value).

We can't use ferny's builtin `do_hostkey()` responder for this, as that
requires `ferny.Session(handle_host_key=True)`, and that API is not
flexible enough to handle our ssh command modifications and the extra
beiboot_helper handler. This needs some bigger redesign, see cockpit-project#19668.

So just recognize and parse SSH's host key prompts, and rely on our
integration tests to spot breakage in future distro releases.

This enables the login page's host key localstorage mechanism, so adjust
TestLogin.testLoginSshBeiboot to only expect the host key on the first
login attempt.
martinpitt added a commit to martinpitt/cockpit that referenced this pull request Jun 27, 2024
@martinpitt
pybridge: Handle ssh host key prompts in beiboot
1d96c4e 
Stop treating host key prompts as generic conversation messages. We want
the UI to handle them properly, with some verbiage/buttons and the
recipe for validating host keys, instead of letting the user type "yes".
The login page recognizes these through the presence of the `host-key`
authorize field (and irritatingly, an extra `default` field with the
actual value).

We can't use ferny's builtin `do_hostkey()` responder for this, as that
requires `ferny.Session(handle_host_key=True)`, and that API is not
flexible enough to handle our ssh command modifications and the extra
beiboot_helper handler. This needs some bigger redesign, see cockpit-project#19668.

So just recognize and parse SSH's host key prompts, and rely on our
integration tests to spot breakage in future distro releases.

This enables the login page's host key localstorage mechanism, so adjust
TestLogin.testLoginSshBeiboot to only expect the host key on the first
login attempt.
martinpitt added a commit to martinpitt/cockpit that referenced this pull request Jun 29, 2024
@martinpitt
pybridge: Handle ssh host key prompts in beiboot
9fb52b9 
Stop treating host key prompts as generic conversation messages. We want
the UI to handle them properly, with some verbiage/buttons and the
recipe for validating host keys, instead of letting the user type "yes".
The login page recognizes these through the presence of the `host-key`
authorize field (and irritatingly, an extra `default` field with the
actual value).

We can't use ferny's builtin `do_hostkey()` responder for this, as that
requires `ferny.Session(handle_host_key=True)`, and that API is not
flexible enough to handle our ssh command modifications and the extra
beiboot_helper handler. This needs some bigger redesign, see cockpit-project#19668.

So just recognize and parse SSH's host key prompts, and rely on our
integration tests to spot breakage in future distro releases.

This enables the login page's host key localstorage mechanism, so adjust
TestLogin.testLoginSshBeiboot to only expect the host key on the first
login attempt.
allisonkarlitskaya pushed a commit to martinpitt/cockpit that referenced this pull request Aug 20, 2024
@martinpitt @allisonkarlitskaya
pybridge: Handle ssh host key prompts in beiboot
ce6693c 
Stop treating host key prompts as generic conversation messages. We want
the UI to handle them properly, with some verbiage/buttons and the
recipe for validating host keys, instead of letting the user type "yes".
The login page recognizes these through the presence of the `host-key`
authorize field (and irritatingly, an extra `default` field with the
actual value).

We can't use ferny's builtin `do_hostkey()` responder for this, as that
requires `ferny.Session(handle_host_key=True)`, and that API is not
flexible enough to handle our ssh command modifications and the extra
beiboot_helper handler. This needs some bigger redesign, see cockpit-project#19668.

So just recognize and parse SSH's host key prompts, and rely on our
integration tests to spot breakage in future distro releases.

This enables the login page's host key localstorage mechanism, so adjust
TestLogin.testLoginSshBeiboot to only expect the host key on the first
login attempt.
martinpitt added a commit to martinpitt/cockpit that referenced this pull request Aug 28, 2024
@martinpitt
beiboot: Handle ssh host key prompts
c022968 
Stop treating host key prompts as generic conversation messages. We want
the UI to handle them properly, with some verbiage/buttons and the
recipe for validating host keys, instead of letting the user type "yes".
The login page recognizes these through the presence of the `host-key`
authorize field (and irritatingly, an extra `default` field with the
actual value).

We can't use ferny's builtin `do_hostkey()` responder for this, as that
requires `ferny.Session(handle_host_key=True)`, and that API is not
flexible enough to handle our ssh command modifications and the extra
beiboot_helper handler. This needs some bigger redesign, see cockpit-project#19668.

So just recognize and parse SSH's host key prompts, and rely on our
integration tests to spot breakage in future distro releases.

This enables the login page's host key localstorage mechanism, so adjust
TestLogin.testLoginSshBeiboot to only expect the host key on the first
login attempt.
martinpitt added a commit to martinpitt/cockpit that referenced this pull request Aug 30, 2024
@martinpitt
beiboot: Handle ssh host key prompts
10acfad 
Stop treating host key prompts as generic conversation messages. We want
the UI to handle them properly, with some verbiage/buttons and the
UI/recipe for confirming/validating host keys, instead of letting the
user type "yes". The login page recognizes these through the presence of
the `host-key` authorize field.

We can't use ferny's builtin `do_hostkey()` responder for this, as that
requires `ferny.Session(handle_host_key=True)`, and that API is not
flexible enough to handle our ssh command modifications and the extra
beiboot_helper handler. This needs some bigger redesign, see cockpit-project#19668.

So just recognize and parse SSH's host key prompts, and rely on our
integration tests to spot breakage in future distro releases.

We want to keep using/storing full host keys

While cockpit-ssh gave us the full host key right away during
conversation, ssh (and thus ferny/beiboot) don't work that way: During
conversation we only get the fingerprint. So for the "sending"
direction, utilize the reently introduced temporary UserKnownHostsFile
feature of beiboot, and send the known_hosts entry for the given host as
part of the `Authorization:` header. For the "receiving" side we need to
jump through a few hoops:

 * For a previously unknown host, we only get the full host key after a
   successful login, as part of the GET /login's `login-data` response.
   So defer updating our localStorage's `known_hosts` database until
   then.

 * ssh (and thus ferny/beiboot) don't report changed host keys as part
   of conversation, but immediatley abort. So remember that state in
   `ssh_host_key_change_host`, and re-attempt the login without sending
   known_hosts data. Our usual logic in `do_hostkey_verification()` will
   notice the change and present the correct dialog.

 * For a changed host key where the login fails due to wrong
   credentials, the login page never receives the new host key whose
   fingerprint the user just confirmed. So we can't remember that
   confirmation, and the next time the user has to re-confirm the
   changed key. cockpit-project#20954 provides some required plumbing for that. In the
   meantime, this seems acceptable as long as cockpit-beiboot isn't the
   default bastion host implementation yet.

Adjust TestLogin.testLoginSshBeiboot to only expect the host key on the
first login attempt. Add testing of changed host key behaviour.
martinpitt added a commit to martinpitt/cockpit that referenced this pull request Aug 30, 2024
@martinpitt
beiboot: Handle ssh host key prompts
93654e4 
Stop treating host key prompts as generic conversation messages. We want
the UI to handle them properly, with some verbiage/buttons and the
UI/recipe for confirming/validating host keys, instead of letting the
user type "yes". The login page recognizes these through the presence of
the `host-key` authorize field.

We can't use ferny's builtin `do_hostkey()` responder for this, as that
requires `ferny.Session(handle_host_key=True)`, and that API is not
flexible enough to handle our ssh command modifications and the extra
beiboot_helper handler. This needs some bigger redesign, see cockpit-project#19668.

So just recognize and parse SSH's host key prompts, and rely on our
integration tests to spot breakage in future distro releases.

We want to keep using/storing full host keys

While cockpit-ssh gave us the full host key right away during
conversation, ssh (and thus ferny/beiboot) don't work that way: During
conversation we only get the fingerprint. So for the "sending"
direction, utilize the reently introduced temporary UserKnownHostsFile
feature of beiboot, and send the known_hosts entry for the given host as
part of the `Authorization:` header. For the "receiving" side we need to
jump through a few hoops:

 * For a previously unknown host, we only get the full host key after a
   successful login, as part of the GET /login's `login-data` response.
   So defer updating our localStorage's `known_hosts` database until
   then.

 * ssh (and thus ferny/beiboot) don't report changed host keys as part
   of conversation, but immediatley abort. So remember that state in
   `ssh_host_key_change_host`, and re-attempt the login without sending
   known_hosts data. Our usual logic in `do_hostkey_verification()` will
   notice the change and present the correct dialog.

 * For a changed host key where the login fails due to wrong
   credentials, the login page never receives the new host key whose
   fingerprint the user just confirmed. So we can't remember that
   confirmation, and the next time the user has to re-confirm the
   changed key. cockpit-project#20954 provides some required plumbing for that. In the
   meantime, this seems acceptable as long as cockpit-beiboot isn't the
   default bastion host implementation yet.

Adjust TestLogin.testLoginSshBeiboot to only expect the host key on the
first login attempt. Add testing of changed host key behaviour.
martinpitt added a commit to martinpitt/cockpit that referenced this pull request Aug 30, 2024
@martinpitt
beiboot: Handle ssh host key prompts
8a5f558 
Stop treating host key prompts as generic conversation messages. We want
the UI to handle them properly, with some verbiage/buttons and the
UI/recipe for confirming/validating host keys, instead of letting the
user type "yes". The login page recognizes these through the presence of
the `host-key` authorize field.

We can't use ferny's builtin `do_hostkey()` responder for this, as that
requires `ferny.Session(handle_host_key=True)`, and that API is not
flexible enough to handle our ssh command modifications and the extra
beiboot_helper handler. This needs some bigger redesign, see cockpit-project#19668.

So just recognize and parse SSH's host key prompts, and rely on our
integration tests to spot breakage in future distro releases.

We want to keep using/storing full host keys

While cockpit-ssh gave us the full host key right away during
conversation, ssh (and thus ferny/beiboot) don't work that way: During
conversation we only get the fingerprint. So for the "sending"
direction, utilize the reently introduced temporary UserKnownHostsFile
feature of beiboot, and send the known_hosts entry for the given host as
part of the `Authorization:` header. For the "receiving" side we need to
jump through a few hoops:

 * For a previously unknown host, we only get the full host key after a
   successful login, as part of the GET /login's `login-data` response.
   So defer updating our localStorage's `known_hosts` database until
   then.

 * ssh (and thus ferny/beiboot) don't report changed host keys as part
   of conversation, but immediatley abort. So remember that state in
   `ssh_host_key_change_host`, and re-attempt the login without sending
   known_hosts data. Our usual logic in `do_hostkey_verification()` will
   notice the change and present the correct dialog.

 * For a changed host key where the login fails due to wrong
   credentials, the login page never receives the new host key whose
   fingerprint the user just confirmed. So we can't remember that
   confirmation, and the next time the user has to re-confirm the
   changed key. cockpit-project#20954 provides some required plumbing for that. In the
   meantime, this seems acceptable as long as cockpit-beiboot isn't the
   default bastion host implementation yet.

Adjust TestLogin.testLoginSshBeiboot to only expect the host key on the
first login attempt. Add testing of changed host key behaviour.
martinpitt added a commit to martinpitt/cockpit that referenced this pull request Sep 1, 2024
@martinpitt
beiboot: Handle ssh host key prompts
6ec8e6d 
Stop treating host key prompts as generic conversation messages. We want
the UI to handle them properly, with some verbiage/buttons and the
UI/recipe for confirming/validating host keys, instead of letting the
user type "yes". The login page recognizes these through the presence of
the `host-key` authorize field.

We can't use ferny's builtin `do_hostkey()` responder for this, as that
requires `ferny.Session(handle_host_key=True)`, and that API is not
flexible enough to handle our ssh command modifications and the extra
beiboot_helper handler. This needs some bigger redesign, see cockpit-project#19668.

So just recognize and parse SSH's host key prompts, and rely on our
integration tests to spot breakage in future distro releases.

We want to keep using/storing full host keys

While cockpit-ssh gave us the full host key right away during
conversation, ssh (and thus ferny/beiboot) don't work that way: During
conversation we only get the fingerprint. So for the "sending"
direction, utilize the reently introduced temporary UserKnownHostsFile
feature of beiboot, and send the known_hosts entry for the given host as
part of the `Authorization:` header. For the "receiving" side we need to
jump through a few hoops:

 * For a previously unknown host, we only get the full host key after a
   successful login, as part of the GET /login's `login-data` response.
   So defer updating our localStorage's `known_hosts` database until
   then.

 * ssh (and thus ferny/beiboot) don't report changed host keys as part
   of conversation, but immediatley abort. So remember that state in
   `ssh_host_key_change_host`, and re-attempt the login without sending
   known_hosts data. Our usual logic in `do_hostkey_verification()` will
   notice the change and present the correct dialog.

 * For a changed host key where the login fails due to wrong
   credentials, the login page never receives the new host key whose
   fingerprint the user just confirmed. So we can't remember that
   confirmation, and the next time the user has to re-confirm the
   changed key. cockpit-project#20954 provides some required plumbing for that. In the
   meantime, this seems acceptable as long as cockpit-beiboot isn't the
   default bastion host implementation yet.

Adjust TestLogin.testLoginSshBeiboot to only expect the host key on the
first login attempt. Add testing of changed host key behaviour.
martinpitt added a commit to martinpitt/cockpit that referenced this pull request Sep 1, 2024
@martinpitt
beiboot: Handle ssh host key prompts
50ef6df 
Stop treating host key prompts as generic conversation messages. We want
the UI to handle them properly, with some verbiage/buttons and the
UI/recipe for confirming/validating host keys, instead of letting the
user type "yes". The login page recognizes these through the presence of
the `host-key` authorize field.

We can't use ferny's builtin `do_hostkey()` responder for this, as that
requires `ferny.Session(handle_host_key=True)`, and that API is not
flexible enough to handle our ssh command modifications and the extra
beiboot_helper handler. This needs some bigger redesign, see cockpit-project#19668.

So just recognize and parse SSH's host key prompts, and rely on our
integration tests to spot breakage in future distro releases.

We want to keep using/storing full host keys

While cockpit-ssh gave us the full host key right away during
conversation, ssh (and thus ferny/beiboot) don't work that way: During
conversation we only get the fingerprint. So for the "sending"
direction, utilize the reently introduced temporary UserKnownHostsFile
feature of beiboot, and send the known_hosts entry for the given host as
part of the `Authorization:` header. For the "receiving" side we need to
jump through a few hoops:

 * For a previously unknown host, we only get the full host key after a
   successful login, as part of the GET /login's `login-data` response.
   So defer updating our localStorage's `known_hosts` database until
   then.

 * ssh (and thus ferny/beiboot) don't report changed host keys as part
   of conversation, but immediatley abort. So remember that state in
   `ssh_host_key_change_host`, and re-attempt the login without sending
   known_hosts data. Our usual logic in `do_hostkey_verification()` will
   notice the change and present the correct dialog.

 * For a changed host key where the login fails due to wrong
   credentials, the login page never receives the new host key whose
   fingerprint the user just confirmed. So we can't remember that
   confirmation, and the next time the user has to re-confirm the
   changed key. cockpit-project#20954 provides some required plumbing for that. In the
   meantime, this seems acceptable as long as cockpit-beiboot isn't the
   default bastion host implementation yet.

Adjust TestLogin.testLoginSshBeiboot to only expect the host key on the
first login attempt. Add testing of changed host key behaviour.
martinpitt added a commit to martinpitt/cockpit that referenced this pull request Sep 1, 2024
@martinpitt
beiboot: Handle ssh host key prompts
d7a5835 
Stop treating host key prompts as generic conversation messages. We want
the UI to handle them properly, with some verbiage/buttons and the
UI/recipe for confirming/validating host keys, instead of letting the
user type "yes". The login page recognizes these through the presence of
the `host-key` authorize field.

We can't use ferny's builtin `do_hostkey()` responder for this, as that
requires `ferny.Session(handle_host_key=True)`, and that API is not
flexible enough to handle our ssh command modifications and the extra
beiboot_helper handler. This needs some bigger redesign, see cockpit-project#19668.

So just recognize and parse SSH's host key prompts, and rely on our
integration tests to spot breakage in future distro releases.

We want to keep using/storing full host keys

While cockpit-ssh gave us the full host key right away during
conversation, ssh (and thus ferny/beiboot) don't work that way: During
conversation we only get the fingerprint. So for the "sending"
direction, utilize the reently introduced temporary UserKnownHostsFile
feature of beiboot, and send the known_hosts entry for the given host as
part of the `Authorization:` header. For the "receiving" side we need to
jump through a few hoops:

 * For a previously unknown host, we only get the full host key after a
   successful login, as part of the GET /login's `login-data` response.
   So defer updating our localStorage's `known_hosts` database until
   then.

 * ssh (and thus ferny/beiboot) don't report changed host keys as part
   of conversation, but immediatley abort. So remember that state in
   `ssh_host_key_change_host`, and re-attempt the login without sending
   known_hosts data. Our usual logic in `do_hostkey_verification()` will
   notice the change and present the correct dialog.

 * For a changed host key where the login fails due to wrong
   credentials, the login page never receives the new host key whose
   fingerprint the user just confirmed. So we can't remember that
   confirmation, and the next time the user has to re-confirm the
   changed key. cockpit-project#20954 provides some required plumbing for that. In the
   meantime, this seems acceptable as long as cockpit-beiboot isn't the
   default bastion host implementation yet.

Adjust TestLogin.testLoginSshBeiboot to only expect the host key on the
first login attempt. Add testing of changed host key behaviour.
martinpitt added a commit to martinpitt/cockpit that referenced this pull request Sep 2, 2024
@martinpitt
beiboot: Handle ssh host key prompts
daf7670 
Stop treating host key prompts as generic conversation messages. We want
the UI to handle them properly, with some verbiage/buttons and the
UI/recipe for confirming/validating host keys, instead of letting the
user type "yes". The login page recognizes these through the presence of
the `host-key` authorize field.

We can't use ferny's builtin `do_hostkey()` responder for this, as that
requires `ferny.Session(handle_host_key=True)`, and that API is not
flexible enough to handle our ssh command modifications and the extra
beiboot_helper handler. This needs some bigger redesign, see cockpit-project#19668.

So just recognize and parse SSH's host key prompts, and rely on our
integration tests to spot breakage in future distro releases.

We want to keep using/storing full host keys

While cockpit-ssh gave us the full host key right away during
conversation, ssh (and thus ferny/beiboot) don't work that way: During
conversation we only get the fingerprint. So for the "sending"
direction, utilize the reently introduced temporary UserKnownHostsFile
feature of beiboot, and send the known_hosts entry for the given host as
part of the `Authorization:` header. For the "receiving" side we need to
jump through a few hoops:

 * For a previously unknown host, we only get the full host key after a
   successful login, as part of the GET /login's `login-data` response.
   So defer updating our localStorage's `known_hosts` database until
   then.

 * ssh (and thus ferny/beiboot) don't report changed host keys as part
   of conversation, but immediatley abort. So remember that state in
   `ssh_host_key_change_host`, and re-attempt the login without sending
   known_hosts data. Our usual logic in `do_hostkey_verification()` will
   notice the change and present the correct dialog.

 * For a changed host key where the login fails due to wrong
   credentials, the login page never receives the new host key whose
   fingerprint the user just confirmed. So we can't remember that
   confirmation, and the next time the user has to re-confirm the
   changed key. cockpit-project#20954 provides some required plumbing for that. In the
   meantime, this seems acceptable as long as cockpit-beiboot isn't the
   default bastion host implementation yet.

Adjust TestLogin.testLoginSshBeiboot to only expect the host key on the
first login attempt. Add testing of changed host key behaviour.
martinpitt added a commit to martinpitt/cockpit that referenced this pull request Sep 2, 2024
@martinpitt
beiboot: Handle ssh host key prompts
8de5656 
Stop treating host key prompts as generic conversation messages. We want
the UI to handle them properly, with some verbiage/buttons and the
UI/recipe for confirming/validating host keys, instead of letting the
user type "yes". The login page recognizes these through the presence of
the `host-key` authorize field.

We can't use ferny's builtin `do_hostkey()` responder for this, as that
requires `ferny.Session(handle_host_key=True)`, and that API is not
flexible enough to handle our ssh command modifications and the extra
beiboot_helper handler. This needs some bigger redesign, see cockpit-project#19668.

So just recognize and parse SSH's host key prompts, and rely on our
integration tests to spot breakage in future distro releases.

We want to keep using/storing full host keys

While cockpit-ssh gave us the full host key right away during
conversation, ssh (and thus ferny/beiboot) don't work that way: During
conversation we only get the fingerprint. So for the "sending"
direction, utilize the reently introduced temporary UserKnownHostsFile
feature of beiboot, and send the known_hosts entry for the given host as
part of the `Authorization:` header. For the "receiving" side we need to
jump through a few hoops:

 * For a previously unknown host and a successful login, we only get the
   full host key as part of the GET /login's `login-data` response. So
   defer updating our localStorage's `known_hosts` database during the
   conversation until that happens. For a failed login, get the
   updated/confirmed host key from the protocol error message.

 * ssh (and thus ferny/beiboot) don't report changed host keys as part
   of conversation, but immediatley abort. So remember that state in
   `ssh_host_key_change_host`, and re-attempt the login without sending
   known_hosts data. Our usual logic in `do_hostkey_verification()` will
   notice the change and present the correct dialog.

Adjust TestLogin.testLoginSshBeiboot to only expect the host key on the
first login attempt. Add testing of changed host key behaviour.
martinpitt added a commit to martinpitt/cockpit that referenced this pull request Sep 2, 2024
@martinpitt
beiboot: Handle ssh host key prompts
9e09226 
Stop treating host key prompts as generic conversation messages. We want
the UI to handle them properly, with some verbiage/buttons and the
UI/recipe for confirming/validating host keys, instead of letting the
user type "yes". The login page recognizes these through the presence of
the `host-key` authorize field.

We can't use ferny's builtin `do_hostkey()` responder for this, as that
requires `ferny.Session(handle_host_key=True)`, and that API is not
flexible enough to handle our ssh command modifications and the extra
beiboot_helper handler. This needs some bigger redesign, see cockpit-project#19668.

So just recognize and parse SSH's host key prompts, and rely on our
integration tests to spot breakage in future distro releases.

While cockpit-ssh gave us the full host key right away during
conversation, ssh (and thus ferny/beiboot) don't work that way: During
conversation we only get the fingerprint. So for the sending direction,
utilize the recently introduced temporary UserKnownHostsFile feature of
beiboot, and send the known_hosts entry for the given host as part of
the `Authorization:` header. For the receiving direction we need to
handle three cases:

 * For a previously unknown host and a successful login, we only get the
   full host key as part of the GET /login's `login-data` response. So
   defer updating our localStorage's `known_hosts` database during the
   conversation until that happens.

 * For a failed login (like wrong password) after already confirming the
   key change, get the host key from the protocol error message.

 * ssh (and thus ferny/beiboot) don't report changed host keys as part
   of conversation, but immediatley abort. So remember that state in
   `ssh_host_key_change_host`, and re-attempt the login without sending
   known_hosts data. Our usual logic in `do_hostkey_verification()` will
   notice the change and present the correct dialog.

Adjust TestLogin.testLoginSshBeiboot to only expect the host key on the
first login attempt. Add testing of changed host key behaviour.
martinpitt added a commit to martinpitt/cockpit that referenced this pull request Sep 2, 2024
@martinpitt
beiboot: Handle ssh host key prompts
8a122d2 
Stop treating host key prompts as generic conversation messages. We want
the UI to handle them properly, with some verbiage/buttons and the
UI/recipe for confirming/validating host keys, instead of letting the
user type "yes". The login page recognizes these through the presence of
the `host-key` authorize field.

We can't use ferny's builtin `do_hostkey()` responder for this, as that
requires `ferny.Session(handle_host_key=True)`, and that API is not
flexible enough to handle our ssh command modifications and the extra
beiboot_helper handler. This needs some bigger redesign, see cockpit-project#19668.

So just recognize and parse SSH's host key prompts, and rely on our
integration tests to spot breakage in future distro releases.

While cockpit-ssh gave us the full host key right away during
conversation, ssh (and thus ferny/beiboot) don't work that way: During
conversation we only get the fingerprint. So for the sending direction,
utilize the recently introduced temporary UserKnownHostsFile feature of
beiboot, and send the known_hosts entry for the given host as part of
the `Authorization:` header. For the receiving direction we need to
handle three cases:

 * For a previously unknown host and a successful login, we only get the
   full host key as part of the GET /login's `login-data` response. So
   defer updating our localStorage's `known_hosts` database during the
   conversation until that happens.

 * For a failed login (like wrong password) after already confirming the
   key change, get the host key from the protocol error message.

 * ssh (and thus ferny/beiboot) don't report changed host keys as part
   of conversation, but immediatley abort. So remember that state in
   `ssh_host_key_change_host`, and re-attempt the login without sending
   known_hosts data. Our usual logic in `do_hostkey_verification()` will
   notice the change and present the correct dialog.

Adjust TestLogin.testLoginSshBeiboot to only expect the host key on the
first login attempt. Add testing of changed host key behaviour.
martinpitt added a commit to martinpitt/cockpit that referenced this pull request Sep 2, 2024
@martinpitt
beiboot: Handle ssh host key prompts
1bdf790 
Stop treating host key prompts as generic conversation messages. We want
the UI to handle them properly, with some verbiage/buttons and the
UI/recipe for confirming/validating host keys, instead of letting the
user type "yes". The login page recognizes these through the presence of
the `host-key` authorize field.

We can't use ferny's builtin `do_hostkey()` responder for this, as that
requires `ferny.Session(handle_host_key=True)`, and that API is not
flexible enough to handle our ssh command modifications and the extra
beiboot_helper handler. This needs some bigger redesign, see cockpit-project#19668.

So just recognize and parse SSH's host key prompts, and rely on our
integration tests to spot breakage in future distro releases.

While cockpit-ssh gave us the full host key right away during
conversation, ssh (and thus ferny/beiboot) don't work that way: During
conversation we only get the fingerprint. So for the sending direction,
utilize the recently introduced temporary UserKnownHostsFile feature of
beiboot, and send the known_hosts entry for the given host as part of
the `Authorization:` header. For the receiving direction we need to
handle three cases:

 * For a previously unknown host and a successful login, we only get the
   full host key as part of the GET /login's `login-data` response. So
   defer updating our localStorage's `known_hosts` database during the
   conversation until that happens.

 * For a failed login (like wrong password) after already confirming the
   key change, get the host key from the protocol error message.

 * ssh (and thus ferny/beiboot) don't report changed host keys as part
   of conversation, but immediatley abort. So remember that state in
   `ssh_host_key_change_host`, and re-attempt the login without sending
   known_hosts data. Our usual logic in `do_hostkey_verification()` will
   notice the change and present the correct dialog.

Adjust TestLogin.testLoginSshBeiboot to only expect the host key on the
first login attempt. Add testing of changed host key behaviour.
martinpitt added a commit to martinpitt/cockpit that referenced this pull request Sep 3, 2024
@martinpitt
beiboot: Handle ssh host key prompts
e5e4df2 
Stop treating host key prompts as generic conversation messages. We want
the UI to handle them properly, with some verbiage/buttons and the
UI/recipe for confirming/validating host keys, instead of letting the
user type "yes". The login page recognizes these through the presence of
the `host-key` authorize field.

We can't use ferny's builtin `do_hostkey()` responder for this, as that
requires `ferny.Session(handle_host_key=True)`, and that API is not
flexible enough to handle our ssh command modifications and the extra
beiboot_helper handler. This needs some bigger redesign, see cockpit-project#19668.

So just recognize and parse SSH's host key prompts, and rely on our
integration tests to spot breakage in future distro releases.

While cockpit-ssh gave us the full host key right away during
conversation, ssh (and thus ferny/beiboot) don't work that way: During
conversation we only get the fingerprint. So for the sending direction,
utilize the recently introduced temporary UserKnownHostsFile feature of
beiboot, and send the known_hosts entry for the given host as part of
the `Authorization:` header. For the receiving direction we need to
handle three cases:

 * For a previously unknown host and a successful login, we only get the
   full host key as part of the GET /login's `login-data` response. So
   defer updating our localStorage's `known_hosts` database during the
   conversation until that happens.

 * For a failed login (like wrong password) after already confirming the
   key change, get the host key from the protocol error message.

 * ssh (and thus ferny/beiboot) don't report changed host keys as part
   of conversation, but immediatley abort. So remember that state in
   `ssh_host_key_change_host`, and re-attempt the login without sending
   known_hosts data. Our usual logic in `do_hostkey_verification()` will
   notice the change and present the correct dialog.

Adjust TestLogin.testLoginSshBeiboot to only expect the host key on the
first login attempt. Add testing of changed host key behaviour.
martinpitt added a commit to martinpitt/cockpit that referenced this pull request Sep 3, 2024
@martinpitt
beiboot: Handle ssh host key prompts
3f56095 
Stop treating host key prompts as generic conversation messages. We want
the UI to handle them properly, with some verbiage/buttons and the
UI/recipe for confirming/validating host keys, instead of letting the
user type "yes". The login page recognizes these through the presence of
the `host-key` authorize field.

We can't use ferny's builtin `do_hostkey()` responder for this, as that
requires `ferny.Session(handle_host_key=True)`, and that API is not
flexible enough to handle our ssh command modifications and the extra
beiboot_helper handler. This needs some bigger redesign, see cockpit-project#19668.

So just recognize and parse SSH's host key prompts, and rely on our
integration tests to spot breakage in future distro releases.

While cockpit-ssh gave us the full host key right away during
conversation, ssh (and thus ferny/beiboot) don't work that way: During
conversation we only get the fingerprint. So for the sending direction,
utilize the recently introduced temporary UserKnownHostsFile feature of
beiboot, and send the known_hosts entry for the given host as part of
the `Authorization:` header. For the receiving direction we need to
handle three cases:

 * For a previously unknown host and a successful login, we only get the
   full host key as part of the GET /login's `login-data` response. So
   defer updating our localStorage's `known_hosts` database during the
   conversation until that happens.

 * For a failed login (like wrong password) after already confirming the
   key change, get the host key from the protocol error message.

 * ssh (and thus ferny/beiboot) don't report changed host keys as part
   of conversation, but immediatley abort. So remember that state in
   `ssh_host_key_change_host`, and re-attempt the login without sending
   known_hosts data. Our usual logic in `do_hostkey_verification()` will
   notice the change and present the correct dialog.

Adjust TestLogin.testLoginSshBeiboot to only expect the host key on the
first login attempt. Add testing of changed host key behaviour.
martinpitt added a commit to martinpitt/cockpit that referenced this pull request Sep 3, 2024
@martinpitt
beiboot: Handle ssh host key prompts
0d9ec09 
Stop treating host key prompts as generic conversation messages. We want
the UI to handle them properly, with some verbiage/buttons and the
UI/recipe for confirming/validating host keys, instead of letting the
user type "yes". The login page recognizes these through the presence of
the `host-key` authorize field.

We can't use ferny's builtin `do_hostkey()` responder for this, as that
requires `ferny.Session(handle_host_key=True)`, and that API is not
flexible enough to handle our ssh command modifications and the extra
beiboot_helper handler. This needs some bigger redesign, see cockpit-project#19668.

So just recognize and parse SSH's host key prompts, and rely on our
integration tests to spot breakage in future distro releases.

While cockpit-ssh gave us the full host key right away during
conversation, ssh (and thus ferny/beiboot) don't work that way: During
conversation we only get the fingerprint. So for the sending direction,
utilize the recently introduced temporary UserKnownHostsFile feature of
beiboot, and send the known_hosts entry for the given host as part of
the `Authorization:` header. For the receiving direction we need to
handle three cases:

 * For a previously unknown host and a successful login, we only get the
   full host key as part of the GET /login's `login-data` response. So
   defer updating our localStorage's `known_hosts` database during the
   conversation until that happens.

 * For a failed login (like wrong password) after already confirming the
   key change, get the host key from the protocol error message.

 * ssh (and thus ferny/beiboot) don't report changed host keys as part
   of conversation, but immediatley abort. So remember that state in
   `ssh_host_key_change_host`, and re-attempt the login without sending
   known_hosts data. Our usual logic in `do_hostkey_verification()` will
   notice the change and present the correct dialog.

Adjust TestLogin.testLoginSshBeiboot to only expect the host key on the
first login attempt. Add testing of changed host key behaviour.
martinpitt added a commit to martinpitt/cockpit that referenced this pull request Sep 3, 2024
@martinpitt
beiboot: Handle ssh host key prompts
f7c3ba6 
Stop treating host key prompts as generic conversation messages. We want
the UI to handle them properly, with some verbiage/buttons and the
UI/recipe for confirming/validating host keys, instead of letting the
user type "yes". The login page recognizes these through the presence of
the `host-key` authorize field.

We can't use ferny's builtin `do_hostkey()` responder for this, as that
requires `ferny.Session(handle_host_key=True)`, and that API is not
flexible enough to handle our ssh command modifications and the extra
beiboot_helper handler. This needs some bigger redesign, see cockpit-project#19668.

So just recognize and parse SSH's host key prompts, and rely on our
integration tests to spot breakage in future distro releases.

While cockpit-ssh gave us the full host key right away during
conversation, ssh (and thus ferny/beiboot) don't work that way: During
conversation we only get the fingerprint. So for the sending direction,
utilize the recently introduced temporary UserKnownHostsFile feature of
beiboot, and send the known_hosts entry for the given host as part of
the `Authorization:` header. For the receiving direction we need to
handle three cases:

 * For a previously unknown host and a successful login, we only get the
   full host key as part of the GET /login's `login-data` response. So
   defer updating our localStorage's `known_hosts` database during the
   conversation until that happens.

 * For a failed login (like wrong password) after already confirming the
   key change, get the host key from the protocol error message.

 * ssh (and thus ferny/beiboot) don't report changed host keys as part
   of conversation, but immediatley abort. So remember that state in
   `ssh_host_key_change_host`, and re-attempt the login without sending
   known_hosts data. Our usual logic in `do_hostkey_verification()` will
   notice the change and present the correct dialog.

Adjust TestLogin.testLoginSshBeiboot to only expect the host key on the
first login attempt. Add testing of changed host key behaviour.
martinpitt added a commit to martinpitt/cockpit that referenced this pull request Sep 19, 2024
@martinpitt
beiboot: Handle ssh host key prompts
1cd9453 
Stop treating host key prompts as generic conversation messages. We want
the UI to handle them properly, with some verbiage/buttons and the
UI/recipe for confirming/validating host keys, instead of letting the
user type "yes". The login page recognizes these through the presence of
the `host-key` authorize field.

We can't use ferny's builtin `do_hostkey()` responder for this, as that
requires `ferny.Session(handle_host_key=True)`, and that API is not
flexible enough to handle our ssh command modifications and the extra
beiboot_helper handler. This needs some bigger redesign, see cockpit-project#19668.

So just recognize and parse SSH's host key prompts, and rely on our
integration tests to spot breakage in future distro releases.

While cockpit-ssh gave us the full host key right away during
conversation, ssh (and thus ferny/beiboot) don't work that way: During
conversation we only get the fingerprint. So for the sending direction,
utilize the recently introduced temporary UserKnownHostsFile feature of
beiboot, and send the known_hosts entry for the given host as part of
the `Authorization:` header. For the receiving direction we need to
handle three cases:

 * For a previously unknown host and a successful login, we only get the
   full host key as part of the GET /login's `login-data` response. So
   defer updating our localStorage's `known_hosts` database during the
   conversation until that happens.

 * For a failed login (like wrong password) after already confirming the
   key change, get the host key from the protocol error message.

 * ssh (and thus ferny/beiboot) don't report changed host keys as part
   of conversation, but immediatley abort. So remember that state in
   `ssh_host_key_change_host`, and re-attempt the login without sending
   known_hosts data. Our usual logic in `do_hostkey_verification()` will
   notice the change and present the correct dialog.

Adjust TestLogin.testLoginSshBeiboot to only expect the host key on the
first login attempt. Add testing of changed host key behaviour.
martinpitt added a commit to martinpitt/cockpit that referenced this pull request Sep 19, 2024
@martinpitt
beiboot: Handle ssh host key prompts
afce95b 
Stop treating host key prompts as generic conversation messages. We want
the UI to handle them properly, with some verbiage/buttons and the
UI/recipe for confirming/validating host keys, instead of letting the
user type "yes". The login page recognizes these through the presence of
the `host-key` authorize field.

We can't use ferny's builtin `do_hostkey()` responder for this, as that
requires `ferny.Session(handle_host_key=True)`, and that API is not
flexible enough to handle our ssh command modifications and the extra
beiboot_helper handler. This needs some bigger redesign, see cockpit-project#19668.

So just recognize and parse SSH's host key prompts, and rely on our
integration tests to spot breakage in future distro releases.

While cockpit-ssh gave us the full host key right away during
conversation, ssh (and thus ferny/beiboot) don't work that way: During
conversation we only get the fingerprint. So for the sending direction,
utilize the recently introduced temporary UserKnownHostsFile feature of
beiboot, and send the known_hosts entry for the given host as part of
the `Authorization:` header. For the receiving direction we need to
handle three cases:

 * For a previously unknown host and a successful login, we only get the
   full host key as part of the GET /login's `login-data` response. So
   defer updating our localStorage's `known_hosts` database during the
   conversation until that happens.

 * For a failed login (like wrong password) after already confirming the
   key change, get the host key from the protocol error message.

 * ssh (and thus ferny/beiboot) don't report changed host keys as part
   of conversation, but immediatley abort. So remember that state in
   `ssh_host_key_change_host`, and re-attempt the login without sending
   known_hosts data. Our usual logic in `do_hostkey_verification()` will
   notice the change and present the correct dialog.

Adjust TestLogin.testLoginSshBeiboot to only expect the host key on the
first login attempt. Add testing of changed host key behaviour.
martinpitt added a commit to martinpitt/cockpit that referenced this pull request Sep 20, 2024
@martinpitt
beiboot: Handle ssh host key prompts
a33575d 
Stop treating host key prompts as generic conversation messages. We want
the UI to handle them properly, with some verbiage/buttons and the
UI/recipe for confirming/validating host keys, instead of letting the
user type "yes". The login page recognizes these through the presence of
the `host-key` authorize field.

We can't use ferny's builtin `do_hostkey()` responder for this, as that
requires `ferny.Session(handle_host_key=True)`, and that API is not
flexible enough to handle our ssh command modifications and the extra
beiboot_helper handler. This needs some bigger redesign, see cockpit-project#19668.

So just recognize and parse SSH's host key prompts, and rely on our
integration tests to spot breakage in future distro releases.

While cockpit-ssh gave us the full host key right away during
conversation, ssh (and thus ferny/beiboot) don't work that way: During
conversation we only get the fingerprint. So for the sending direction,
utilize the recently introduced temporary UserKnownHostsFile feature of
beiboot, and send the known_hosts entry for the given host as part of
the `Authorization:` header. For the receiving direction we need to
handle three cases:

 * For a previously unknown host and a successful login, we only get the
   full host key as part of the GET /login's `login-data` response. So
   defer updating our localStorage's `known_hosts` database during the
   conversation until that happens.

 * For a failed login (like wrong password) after already confirming the
   key change, get the host key from the protocol error message.

 * ssh (and thus ferny/beiboot) don't report changed host keys as part
   of conversation, but immediatley abort. So remember that state in
   `ssh_host_key_change_host`, and re-attempt the login without sending
   known_hosts data. Our usual logic in `do_hostkey_verification()` will
   notice the change and present the correct dialog.

Adjust TestLogin.testLoginSshBeiboot to only expect the host key on the
first login attempt. Add testing of changed host key behaviour.
martinpitt added a commit to martinpitt/cockpit that referenced this pull request Sep 20, 2024
@martinpitt
beiboot: Handle ssh host key prompts
6699c33 
Stop treating host key prompts as generic conversation messages. We want
the UI to handle them properly, with some verbiage/buttons and the
UI/recipe for confirming/validating host keys, instead of letting the
user type "yes". The login page recognizes these through the presence of
the `host-key` authorize field.

We can't use ferny's builtin `do_hostkey()` responder for this, as that
requires `ferny.Session(handle_host_key=True)`, and that API is not
flexible enough to handle our ssh command modifications and the extra
beiboot_helper handler. This needs some bigger redesign, see cockpit-project#19668.

So just recognize and parse SSH's host key prompts, and rely on our
integration tests to spot breakage in future distro releases.

While cockpit-ssh gave us the full host key right away during
conversation, ssh (and thus ferny/beiboot) don't work that way: During
conversation we only get the fingerprint. So for the sending direction,
utilize the recently introduced temporary UserKnownHostsFile feature of
beiboot, and send the known_hosts entry for the given host as part of
the `Authorization:` header. For the receiving direction we need to
handle three cases:

 * For a previously unknown host and a successful login, we only get the
   full host key as part of the GET /login's `login-data` response. So
   defer updating our localStorage's `known_hosts` database during the
   conversation until that happens.

 * For a failed login (like wrong password) after already confirming the
   key change, get the host key from the protocol error message.

 * ssh (and thus ferny/beiboot) don't report changed host keys as part
   of conversation, but immediatley abort. So remember that state in
   `ssh_host_key_change_host`, and re-attempt the login without sending
   known_hosts data. Our usual logic in `do_hostkey_verification()` will
   notice the change and present the correct dialog.

Adjust TestLogin.testLoginSshBeiboot to only expect the host key on the
first login attempt. Add testing of changed host key behaviour.
martinpitt added a commit to martinpitt/cockpit that referenced this pull request Sep 20, 2024
@martinpitt
beiboot: Handle ssh host key prompts
242e2d3 
Stop treating host key prompts as generic conversation messages. We want
the UI to handle them properly, with some verbiage/buttons and the
UI/recipe for confirming/validating host keys, instead of letting the
user type "yes". The login page recognizes these through the presence of
the `host-key` authorize field.

We can't use ferny's builtin `do_hostkey()` responder for this, as that
requires `ferny.Session(handle_host_key=True)`, and that API is not
flexible enough to handle our ssh command modifications and the extra
beiboot_helper handler. This needs some bigger redesign, see cockpit-project#19668.

So just recognize and parse SSH's host key prompts, and rely on our
integration tests to spot breakage in future distro releases.

While cockpit-ssh gave us the full host key right away during
conversation, ssh (and thus ferny/beiboot) don't work that way: During
conversation we only get the fingerprint. So for the sending direction,
utilize the recently introduced temporary UserKnownHostsFile feature of
beiboot, and send the known_hosts entry for the given host as part of
the `Authorization:` header. For the receiving direction we need to
handle three cases:

 * For a previously unknown host and a successful login, we only get the
   full host key as part of the GET /login's `login-data` response. So
   defer updating our localStorage's `known_hosts` database during the
   conversation until that happens.

 * For a failed login (like wrong password) after already confirming the
   key change, get the host key from the protocol error message.

 * ssh (and thus ferny/beiboot) don't report changed host keys as part
   of conversation, but immediatley abort. So remember that state in
   `ssh_host_key_change_host`, and re-attempt the login without sending
   known_hosts data. Our usual logic in `do_hostkey_verification()` will
   notice the change and present the correct dialog.

Adjust TestLogin.testLoginSshBeiboot to only expect the host key on the
first login attempt. Add testing of changed host key behaviour.
martinpitt added a commit to martinpitt/cockpit that referenced this pull request Sep 20, 2024
@martinpitt
beiboot: Handle ssh host key prompts
db8d88c 
Stop treating host key prompts as generic conversation messages. We want
the UI to handle them properly, with some verbiage/buttons and the
UI/recipe for confirming/validating host keys, instead of letting the
user type "yes". The login page recognizes these through the presence of
the `host-key` authorize field.

We can't use ferny's builtin `do_hostkey()` responder for this, as that
requires `ferny.Session(handle_host_key=True)`, and that API is not
flexible enough to handle our ssh command modifications and the extra
beiboot_helper handler. This needs some bigger redesign, see cockpit-project#19668.

So just recognize and parse SSH's host key prompts, and rely on our
integration tests to spot breakage in future distro releases.

While cockpit-ssh gave us the full host key right away during
conversation, ssh (and thus ferny/beiboot) don't work that way: During
conversation we only get the fingerprint. So for the sending direction,
utilize the recently introduced temporary UserKnownHostsFile feature of
beiboot, and send the known_hosts entry for the given host as part of
the `Authorization:` header. For the receiving direction we need to
handle three cases:

 * For a previously unknown host and a successful login, we only get the
   full host key as part of the GET /login's `login-data` response. So
   defer updating our localStorage's `known_hosts` database during the
   conversation until that happens.

 * For a failed login (like wrong password) after already confirming the
   key change, get the host key from the protocol error message.

 * ssh (and thus ferny/beiboot) don't report changed host keys as part
   of conversation, but immediatley abort. So remember that state in
   `ssh_host_key_change_host`, and re-attempt the login without sending
   known_hosts data. Our usual logic in `do_hostkey_verification()` will
   notice the change and present the correct dialog.

Adjust TestLogin.testLoginSshBeiboot to only expect the host key on the
first login attempt. Add testing of changed host key behaviour.
martinpitt added a commit that referenced this pull request Sep 23, 2024
@martinpitt
beiboot: Handle ssh host key prompts
5a73281 
Stop treating host key prompts as generic conversation messages. We want
the UI to handle them properly, with some verbiage/buttons and the
UI/recipe for confirming/validating host keys, instead of letting the
user type "yes". The login page recognizes these through the presence of
the `host-key` authorize field.

We can't use ferny's builtin `do_hostkey()` responder for this, as that
requires `ferny.Session(handle_host_key=True)`, and that API is not
flexible enough to handle our ssh command modifications and the extra
beiboot_helper handler. This needs some bigger redesign, see #19668.

So just recognize and parse SSH's host key prompts, and rely on our
integration tests to spot breakage in future distro releases.

While cockpit-ssh gave us the full host key right away during
conversation, ssh (and thus ferny/beiboot) don't work that way: During
conversation we only get the fingerprint. So for the sending direction,
utilize the recently introduced temporary UserKnownHostsFile feature of
beiboot, and send the known_hosts entry for the given host as part of
the `Authorization:` header. For the receiving direction we need to
handle three cases:

 * For a previously unknown host and a successful login, we only get the
   full host key as part of the GET /login's `login-data` response. So
   defer updating our localStorage's `known_hosts` database during the
   conversation until that happens.

 * For a failed login (like wrong password) after already confirming the
   key change, get the host key from the protocol error message.

 * ssh (and thus ferny/beiboot) don't report changed host keys as part
   of conversation, but immediatley abort. So remember that state in
   `ssh_host_key_change_host`, and re-attempt the login without sending
   known_hosts data. Our usual logic in `do_hostkey_verification()` will
   notice the change and present the correct dialog.

Adjust TestLogin.testLoginSshBeiboot to only expect the host key on the
first login attempt. Add testing of changed host key behaviour.
SludgeGirl pushed a commit to Nykseli/cockpit that referenced this pull request Nov 12, 2024
@martinpitt @SludgeGirl
beiboot: Handle ssh host key prompts
8715cab 
Stop treating host key prompts as generic conversation messages. We want
the UI to handle them properly, with some verbiage/buttons and the
UI/recipe for confirming/validating host keys, instead of letting the
user type "yes". The login page recognizes these through the presence of
the `host-key` authorize field.

We can't use ferny's builtin `do_hostkey()` responder for this, as that
requires `ferny.Session(handle_host_key=True)`, and that API is not
flexible enough to handle our ssh command modifications and the extra
beiboot_helper handler. This needs some bigger redesign, see cockpit-project#19668.

So just recognize and parse SSH's host key prompts, and rely on our
integration tests to spot breakage in future distro releases.

While cockpit-ssh gave us the full host key right away during
conversation, ssh (and thus ferny/beiboot) don't work that way: During
conversation we only get the fingerprint. So for the sending direction,
utilize the recently introduced temporary UserKnownHostsFile feature of
beiboot, and send the known_hosts entry for the given host as part of
the `Authorization:` header. For the receiving direction we need to
handle three cases:

 * For a previously unknown host and a successful login, we only get the
   full host key as part of the GET /login's `login-data` response. So
   defer updating our localStorage's `known_hosts` database during the
   conversation until that happens.

 * For a failed login (like wrong password) after already confirming the
   key change, get the host key from the protocol error message.

 * ssh (and thus ferny/beiboot) don't report changed host keys as part
   of conversation, but immediatley abort. So remember that state in
   `ssh_host_key_change_host`, and re-attempt the login without sending
   known_hosts data. Our usual logic in `do_hostkey_verification()` will
   notice the change and present the correct dialog.

Adjust TestLogin.testLoginSshBeiboot to only expect the host key on the
first login attempt. Add testing of changed host key behaviour.
@allisonkarlitskaya
Copy link
Member Author

allisonkarlitskaya commented Dec 18, 2024

There's been a tonne of related work which improves the chances of being successful with this, and I think it's absolutely still worthwhile, but it's probably a bit of a "start over" at this point.

Let's close this for now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@martinpitt martinpitt martinpitt left review comments

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@allisonkarlitskaya @martinpitt