On Wed, 17 Jun 2020, Rory Campbell-Lange wrote: > > > Secondly, would there be any alteration to the requirement for a > > > "HostCertificate" CA-signed public key (from a private "HostKey") on > > > sshd receiving servers? > > > > I don't understand what you mean here. Could you elabourate? > > My apologies for the poor explanation. Let me try again. > > 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. -d _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
