bugzilla-daemon at mindrot.org
2023-Aug-01 13:19 UTC
[Bug 3597] New: Why do we check both nsession_ids and remote_add_provider when judging whether allow remote addition of FIDO/PKCS11 provider libraries is disabled?
https://bugzilla.mindrot.org/show_bug.cgi?id=3597 Bug ID: 3597 Summary: Why do we check both nsession_ids and remote_add_provider when judging whether allow remote addition of FIDO/PKCS11 provider libraries is disabled? Product: Portable OpenSSH Version: -current Hardware: Other OS: Windows 10 Status: NEW Severity: trivial Priority: P5 Component: ssh-agent Assignee: unassigned-bugs at mindrot.org Reporter: rmsh1216 at 163.com Disallow remote addition of FIDO/PKCS11 provider libraries to ssh-agent by default is introducted in the commit: https://github.com/openssh/openssh-portable/commit/1f2731f5d7a8f8a8385c6031667ed29072c0d92a In my opinion, it is unnecessary for us to check the value of nsession_ids, because nsession_ids is used to count the number of the connections which are opened via "session-bind at openssh.com" agent extension. ``` if (e->nsession_ids != 0 && !remote_add_provider) { verbose("failed add of SK provider \"%.100s\": " "remote addition of providers is disabled", sk_provider); goto out; } ``` Please tell me the reason. Thanks a lot. -- You are receiving this mail because: You are watching the assignee of the bug.
bugzilla-daemon at mindrot.org
2023-Aug-02 02:15 UTC
[Bug 3597] Why do we check both nsession_ids and remote_add_provider when judging whether allow remote addition of FIDO/PKCS11 provider libraries is disabled?
https://bugzilla.mindrot.org/show_bug.cgi?id=3597 Damien Miller <djm at mindrot.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |WORKSFORME Status|NEW |RESOLVED CC| |djm at mindrot.org --- Comment #1 from Damien Miller <djm at mindrot.org> --- remote_add_provider indicates whether the user has allowed remote ssh-agent clients to add PKCS#11 providers. e->nsession_ids>0 indicates that a session is actually remote. A local session will have e->nsession_ids=0. See process_ext_session_bind() in ssh-agent.c and the corresponding authfd.c:ssh_agent_bind_hostkey() code that is called from ssh's clientloop.c:client_request_agent(). -- 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.
bugzilla-daemon at mindrot.org
2023-Aug-02 08:33 UTC
[Bug 3597] Why do we check both nsession_ids and remote_add_provider when judging whether allow remote addition of FIDO/PKCS11 provider libraries is disabled?
https://bugzilla.mindrot.org/show_bug.cgi?id=3597 --- Comment #2 from renmingshuai <rmsh1216 at 163.com> --- (In reply to Damien Miller from comment #1)> remote_add_provider indicates whether the user has allowed remote > ssh-agent clients to add PKCS#11 providers. > > e->nsession_ids>0 indicates that a session is actually remote. A > local session will have e->nsession_ids=0. > > See process_ext_session_bind() in ssh-agent.c and the corresponding > authfd.c:ssh_agent_bind_hostkey() code that is called from ssh's > clientloop.c:client_request_agent().Thanks, I get it. Besides, e->nsession_ids was introduced in openssh-8.9p1. For lower version, before openssh-8.9p1, only checking the value of remote_add_provider is stricter, although it may cause some problems else. -- 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.
bugzilla-daemon at mindrot.org
2023-Aug-02 22:00 UTC
[Bug 3597] Why do we check both nsession_ids and remote_add_provider when judging whether allow remote addition of FIDO/PKCS11 provider libraries is disabled?
https://bugzilla.mindrot.org/show_bug.cgi?id=3597 --- Comment #3 from Damien Miller <djm at mindrot.org> ---> For lower version, before openssh-8.9p1, only checking the > value of remote_add_provider is stricter, although it may > cause some problems else.That won't work. Older versions have no way of telling whether a socket is local or remote, so testing remote_add_provider alone would simply ban all PKCS#11 loading. -- 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.
Possibly Parallel Threads
- ssh-agent hides sk "confirm user presence" message
- OpenSSH not requesting touch on FIDO keys (was: OpenSSH not requesting PIN code for YubiKey)
- OpenSSH not requesting touch on FIDO keys (was: OpenSSH not requesting PIN code for YubiKey)
- Idea: reverse socks proxy
- [PATCH] ssh-pkcs11: allow providing unconditional pin code for PKCS11