openssh bugs - May 2024 - [Bug 3687] New: Leverage publickey-hostbound-v00 on non-constrained keys for better confirmation prompts

https://bugzilla.mindrot.org/show_bug.cgi?id=3687

            Bug ID: 3687
           Summary: Leverage publickey-hostbound-v00 on non-constrained
                    keys for better confirmation prompts
           Product: Portable OpenSSH
           Version: 9.7p1
          Hardware: Other
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: ssh-agent
          Assignee: unassigned-bugs at mindrot.org
          Reporter: paravoid at debian.org

OpenSSH 8.9 implemented the publickey-hostbound-v00 at openssh.com
protocol, which seems to be used exclusively with
restrict-destination-v00 at openssh.com destination constraints.

Additionally, it seems that the feature was designed with "confirm" in
mind as well, and when an SSH with a constrained key is attempted,
ssh-agent adds the requested user to the confirmation prompt:
   xasprintf(&sig_dest, "public key authentication request for "
       "user \"%s\" to listed host", user);
   ...
   if (id->confirm && confirm_key(id, sig_dest) != 0) { 

This is all great, and works well as far as I can tell.

What I'd like to request is to consider altering the confirmation
prompt in this way unconditionally, i.e. even if no destination
constraints were loaded. While at it, it'd be useful to also add the
hostkey to the prompt as well (there's an XXX about that too).

The use case I'm thinking of, is:
  ssh-add -c
  ssh -A user1 at host1
  # confirmation prompt
  # agent socket is now exposed to host1
  ssh user2 at host2
  # confirmation prompt now includes user2 and host2's FP

The confirmation prompt on the second SSH attempt allows the user to
confirm that their key is indeed about to be used for the request they
made, and that the socket wasn't hijacked by another user on host1.

The implementation of this feels relatively trivial, as I think most of
the code is already there and it's a matter of moving it outside of the
"if"? I did a few tests locally and it seems I got all the right data.
This makes me wonder whether there was a reason this wasn't implemented
in the first place?

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3687

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |djm at mindrot.org

--- Comment #1 from Damien Miller <djm at mindrot.org> ---
Yes, that could work but there are some corner cases around certificate
keys and the certificate->plain fallback behaviour in ssh.

My current thinking is that the notification logic in this area is
already a bit over-complicated for ssh-agent, which is supposed to be
as small and simple as possible. I think I'd prefer to delegate as much
notification, confirmation, prompting, etc to an optional external
service that ssh-agent can invoke via a unix domain socket.

That service could receive the entire host binding path (if present),
the type of signature, the destination username, hostkey of the
destination host (if available), details of the public key being used,
etc. and could present this in a much more rich and potentially usable
form than ssh-askpass can.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3687

--- Comment #2 from Damien Miller <djm at mindrot.org> ---
On platforms that use it, you could bridge these messages into dbus to
get idiomatic desktop notifications of key use, etc. too.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=3687

--- Comment #3 from Faidon Liambotis <paravoid at debian.org> ---
Thanks for the quick response! Yeah, I was thinking about that as well,
but thought to take it one step at a time, perfect is the enemy of good
etc. :)

This may be heresy ;) but this is starting to sound a bit like GnuPG's
pinentry IPC? See e.g.
https://velvetcache.org/2023/03/26/a-peek-inside-pinentry/ for a high
level overview of how that looks like. Perhaps there's value in
creating compatibility here, as you'd be able to plug-in into this
ecosystem of GUIs on day 1.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.