Rory Campbell-Lange
2020-Jun-17 06:17 UTC
client host certificates and receiving host configuration
On 17/06/20, Damien Miller (djm at mindrot.org) wrote:> > Firstly, given a host CA signing key on the sshagentca server, would an > > appropriately constructed host certificate added to a forwarded agent > > replace the necessity for a '@cert-authority' line in a user's known_hosts > > file? > > I'm not sure I want to add yet another path (the agent) to ssh's already > twisty host key verification logic. However, a few people have requsted > a KnownHostsCommand option that allows the output of a subprocess to > be used in addition to the usual known_hosts. Would this work for you? > > > 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), 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 Thanks very much Rory
Rory Campbell-Lange
2020-Jun-17 20:51 UTC
client host certificates and receiving host configuration
On 17/06/20, Rory Campbell-Lange (rory at campbell-lange.net) 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), and what part of the normal set of configuration requirements* > does it help with?My apologies -- I'd completely misunderstood the mode of operation of host certificates.
Damien Miller
2020-Jun-18 03:54 UTC
client host certificates and receiving host configuration
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 hostsI 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
Rory Campbell-Lange
2020-Jun-19 10:54 UTC
client host certificates and receiving host configuration
On 18/06/20, Damien Miller (djm at mindrot.org) 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