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-b...@mindrot.org
Reporter: parav...@debian.org
OpenSSH 8.9 implemented the publickey-hostbound-...@openssh.com
protocol, which seems to be used exclusively with
restrict-destination-...@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@host1
# confirmation prompt
# agent socket is now exposed to host1
ssh user2@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.
_______________________________________________
openssh-bugs mailing list
openssh-bugs@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-bugs
