[zhfliz]

> No, as they never get loaded into the ssh binary and are external programs communicating over an interface.

my understanding is that the same would apply if you use ykcs11 in the OpenSSH agent instead of using it directly in `ssh`, which would make this a comparison between (OpenSSH agent + YKCS11) vs e.g., ssh-tpm-agent.

from the qualys report you linked:

> Note to the curious readers: for security reasons, and as explained in the "Background" section below, ssh-agent does not actually load such a shared library in its own address space (where private keys are stored), but in a separate, dedicated process, ssh-pkcs11-helper.

additionally, as I understand it, this basically boils down to use-after-free due to unsafe code, which could occur in either agent implementation, even without loading an extra .so, although the presence of .so loading in general certainly does increase the attack surface.

> `ssh-tpm-agent` is not dealing with secret material.

while the agent is certainly not accessing the private key directly, as long as you can access the agent and make it sign whatever you want, this will still be a very valuable vulnerability, with the only downside (compared to non-HSM keys) that you won't have persistent access to the private key, only temporary access for signing.

this can also be partially mitigated by requiring user interaction for every signing operation, but it's also not necessarily something that works for all use cases, such as when connecting to a few hundred destination hosts.

> There is a separation of concerns here though.

when you compare (OpenSSH agent + YKCS11) to ssh-tpm-agent, they're both separated from the main `ssh` process and communicate through the SSH agent API.

PKCS11 allows you to use `ssh -I /path/to/lib.so` directly, which there doesn't seem to be a comparable alternative for in ssh-tpm-agent, so I'll ignore that feature for now.

[Foxboron]

>additionally, as I understand it, this basically boils down to use-after-free due to unsafe code, which could occur in either agent implementation, even without loading an extra .so, although the presence of .so loading in general certainly does increase the attack surface.

You are not going to see similar exploits available in a program written in Go, it would result in a crash. Not an actual code execution issue.

So you are removing attack surface by not loading shared libraries, and quite a bit of attack surface considering it's not written in C.

> this can also be partially mitigated by requiring user interaction for every signing operation, but it's also not necessarily something that works for all use cases, such as when connecting to a few hundred destination hosts.

Allowing better UX would also allow people to utilize better and more secure defaults. The PKCS11 stuff is general unfriendly and using it correctly as a result gets harder.

This isn't only about attack surface, but also enabling more user friendly tooling.