[Bug 3748] "webauthn-sk-ecdsa-sha2-nistp256 at openssh.com" signature type not supported from ssh agent

[bugzilla-daemon at mindrot.org]

https://bugzilla.mindrot.org/show_bug.cgi?id=3748

--- Comment #12 from Jó Ágila Bitsch <jgilab at gmail.com> ---
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
webauthn-sk-ecdsa-sha2-nistp256 at openssh.org 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 webauthn-sk-ecdsa-sha2-nistp256 at openssh.org 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.