bugzilla-daemon at mindrot.org
2023-Aug-21 22:14 UTC
[Bug 3607] New: Redundant "Confirm user presence"
https://bugzilla.mindrot.org/show_bug.cgi?id=3607 Bug ID: 3607 Summary: Redundant "Confirm user presence" Product: Portable OpenSSH Version: 9.4p1 Hardware: All OS: Linux Status: NEW Severity: enhancement Priority: P5 Component: ssh Assignee: unassigned-bugs at mindrot.org Reporter: bluebird090909 at proton.me Connecting with a security key results in the following behavior: $ ssh tester at testserver Confirm user presence for key ED25519-SK SHA256:7eZ... Enter PIN for ED25519-SK key /home/user/.ssh/id_ed25519_sk-test: (Pin is entered) Confirm user presence for key ED25519-SK SHA256:7eZ... (Authenticator touched) To clarify: After initiating the connection, I get the following two lines immediately: Confirm user presence for key ED25519-SK SHA256:7eZ... Enter PIN for ED25519-SK key /home/user/.ssh/id_ed25519_sk-test: I then enter the PIN and get the next line: Confirm user presence for key ED25519-SK SHA256:7eZ... Then I touch the device (once) and am logged in I never need to touch the device twice to login. The key was generated with the following: ssh-keygen -t ed25519-sk -O resident -O verify-required -O application=ssh:test Both Client and Server are running Arch with OpenSSH 9.4 Used Security Key: Nitrokey 3, Firmware version: v1.5.0 -- You are receiving this mail because: You are watching the assignee of the bug.
bugzilla-daemon at mindrot.org
2023-Aug-21 22:19 UTC
[Bug 3607] Redundant "Confirm user presence"
https://bugzilla.mindrot.org/show_bug.cgi?id=3607 Damien Miller <djm at mindrot.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |WONTFIX CC| |djm at mindrot.org Status|NEW |RESOLVED --- Comment #1 from Damien Miller <djm at mindrot.org> --- Unfortunately some of these can't be avoided as it's impossible to perform some FIDO operations without requiring the user confirm user presence by touching their key. Which operations? We have no way of knowing prior to attempting them, so we've taken the approach of attempting erring on the side of redundantly warning the user rather than risking things hanging while waiting for the user to touch without notice -- 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.