https://bugzilla.mindrot.org/show_bug.cgi?id=3748
--- Comment #12 from Jó Ágila Bitsch <[email protected]> --- I updated the patch here to match the diff of my pull request on github. I was thinking about how to improve the general support for [email protected] signature types and going through the code a bit to investigate, but I need guidance what the best direction would be. The main use case for this signature type is to allow to offload the signature generation to a browser. For the sake of discussion I propose the following general context: An application like https://cockpit-project.org/ (An easy-to-use, integrated, glanceable, and open web-based interface for your servers, that comes with most linux distributions) wants to remotely log into a different server via ssh. Currently it uses password based login or key based login, where the private key is available as a file and added to an ssh agent on a bastion host that is decoded based on the login password. I would prefer if I could use a passkey/fido2 token in the browser instead. Maybe even based on an ssh certificate. The integration between the browser and the ssh binary would most likely be via an alternative ssh-agent implementation. Cockpit in particular allows to provide a unix domain socket based service via javascript, so directly in the browser. Cockpit could open a unix domain socket and set the environment or arguments for the ssh call accordingly to connect to this socket as an ssh-agent. Aside from allowing [email protected] from an agent, there would not be any other code changes necessary to be able to use the well-tested and established openssh binaries themselves. Maybe openssh ssh-agent could provide a way to call into an additional ssh-agent recursively so that a custom provider could provide additional keys via a browser interface but the built-in mechanisms and safety checks from openssh ssh-agent are still in place, but that is not strictly necessary. Now, to what extend should openssh itself produce this type of signatures? The points that would need to be adjusted would be: * ssh-keygen.c main() would need to allow other application strings not starting with "ssh:" when creating a ecdsa-sk key as webauthn signatures only make sense from a web-like origin * ssh-sk.c sshksign() would need to replace the data with the client_data json as is ssh-ecdsa-sk.c webauthn_check_prepare_hash() use a different signature name and transfer the origin, client_data and extensions to sshsk_ecdsa_sig for inclusion in the serialized signature. Is that something that makes sense to the openssh project? As a starting point, I would suggest though that I prepare a very minimal dummy agent in the regression test suite that works with sk-dummy.c based keys and prepare additional tests to ensure the signature type is well supported for the default use cases server login, certificate signing and sshsig. I'm open to any guidance on this topic. -- 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. _______________________________________________ openssh-bugs mailing list [email protected] https://lists.mindrot.org/mailman/listinfo/openssh-bugs
