On 18/06/20, Damien Miller (djm@xxxxxxxxxxx) wrote: > On Wed, 17 Jun 2020, Rory Campbell-Lange wrote: > > Adding a user certificate to a client forwarded agent allows that client > > to use that certificate to authenticate to servers with > > TrustedUserCAKeys set to the public key used to sign the certificate. > > > > What would host certificates added to a client forwarded agent give one > > (if any), > > Hmm, the agent deals with private keys only at present. Do you mean > modifying the agent to support adding the public part of host > certificates? > > If so, then I guess it would be possible to use the agent as a kind of > known_hosts file but there is a lot of glue needed to make that happen > and I'm not sure the agent is an ideal place for it. > > If you do mean adding the private host keys then it would additionally > make host-based authentication possible via the agent but, less > beneficially, give the user and anyone with access to their agent socket > the ability to impersonate those hosts. > > > and what part of the normal set of configuration requirements* > > does it help with? > > > > * normal config : @cert-authority in the client's ~/.ssh/known_hosts; > > setup of appropriate HostCertificate directives on receiving hosts > > I don't think it really helps with this. What you might want to be able > to forward around with you is your database of known_hosts, including > the @cert-authority markers. These are public keys only, plus the host > name(s) they apply to, plus a couple of bits per key of metadata (revoked, > cert-authority, etc.) > > The agent, as it stands, only handles private keys (not public), has > no ancilliary metadata storage and no protocol verbs to perform the > actions needed by host key verification. All these would need to be > added for the agent to be capable of subsuming known_hosts operations. > > However these are sufficiently different to the agent's current role > that it would be worth considering doing it in a different service, > as the agent really needs to be as simple and to present as little > attack surface as possible so it can protect its private keys. Thank you for your thoughtful consideration of my rather misguided enquiries. The agent only having private keys and as small an attack surface as possible makes complete sense. Rory _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
