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

[bugzilla-daemon at mindrot.org]

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.