Bug 1879183
| Summary: | ssh (the client) fails to use signed public key passed via `ssh -i` | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | Christopher J. Ruwe <cjr> |
| Component: | openssh | Assignee: | Jakub Jelen <jjelen> |
| Status: | CLOSED NOTABUG | QA Contact: | BaseOS QE Security Team <qe-baseos-security> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 8.0 | CC: | cjr, tmraz |
| Target Milestone: | rc | ||
| Target Release: | 8.0 | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2020-09-16 08:42:59 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Christopher J. Ruwe
2020-09-15 15:53:22 UTC
> 3) it should neither demand the corresponding private nor the unsigned public key to be present. How the client should then prove to the server it has the private key when it does not have it? The certificate authentication does not replace public key authentication. The certificate file is just public key with some metadata (the same as X509). It is "certification" addition to the public key send on the wire. The private key is always needed also for certificate authentication, otherwise there would be no security at all. Please, check the specification: https://github.com/openssh/openssh-portable/blob/master/PROTOCOL.certkeys To make it clear - the unsigned public key should not be needed. But the private key is absolutely required. Anybody holding the public key would be able to impersonate you otherwise. Thank you for both your answers. What you are telling me then is that _both_ private and signed public keys are _required_? What you are also telling me is that signed keys is not a mechanism different from the "normal" public/private key scheme, but an _extension_ building on the former? That I can actually verify when calling `ssh` with both keys passed as in `ssh -i <private-key> -i <public-and-signed-key> ...`. When only the public-and-signed-key is passed, the client looks for a corresponding private key in the standard locations and fails when none or no matching can be found there, correct? If I have understood correctly so far, it might actually be nice to drop a line in the docs. ssh-keygen(1) elaborates on signed keys in that > Clients or servers may then trust _only_ the CA key and verify its > signature on a certificate rather _than trusting many user/host > keys_. (Emphasis mine) That could - as I have - be misunderstood, which I will explain later. > To make it clear - the unsigned public key should not be needed. But > the private key is absolutely required. Anybody holding the public > key would be able to impersonate you otherwise. Thank you for clarifying that reasoning, I only now understand my error. With the trust relationship worded as in the the ssh-keygen(1) man page ("only"), I imagined "sealed box signing mechanisms", where _noone_ has access to the private key of the CA certificate and thus only the sealed box could impersonate, which it won't. Giving _actual persons_ access to the CA keys completely escaped my notice, even as it is, when I now think about it, probably the default case. Could you please consider dropping a line in the documentation elaborating that 1) "key signing is not separate, but only extends", because 2) otherwise anyone with access to the CA keys, which per default perspective is a human operator, could impersonate? Perhaps it would be helpful to describe how to pass private and signed public keys with `ssh -i ... -i ...` when having keys with or non-default names or locations? In any case, the last explanation has been extremely helpful, thank you very much. (In reply to Christopher J. Ruwe from comment #3) > Thank you for both your answers. > > What you are telling me then is that _both_ private and signed public keys > are _required_? Certainly the private key is needed. Public key should not be needed as it can be trivially extracted from the certificate and from some types of private keys (though it might not be implemented in openssh-8.0p1). But it would need to be tested. > What you are also telling me is that signed keys is not a > mechanism different from the "normal" public/private key scheme, but an > _extension_ building on the former? Right, as described in the previously mentioned PROTOCOL.certkeys. > That I can actually verify when calling `ssh` with both keys passed as in > `ssh -i <private-key> -i <public-and-signed-key> ...`. When only the > public-and-signed-key is passed, the client looks for a > corresponding private key in the standard locations and fails when none or > no matching can be found there, correct? The certificate, if in non-standard location or non-standard naming from the private key specified by -i, needs to be specified with -oCertificateFile= from manual pages. It might work also with -i, but might go into weird issues too. The manual page for ssh describes how the certificates for keys are searched (not the other way round), so if it has correct suffix, it might work to pass only the private key. But I did not try that. > If I have understood correctly so far, it might actually be nice to drop a > line in the docs. ssh-keygen(1) elaborates on signed keys in that > > > Clients or servers may then trust _only_ the CA key and verify its > > signature on a certificate rather _than trusting many user/host > > keys_. (Emphasis mine) This is still correct. You trust the CA by specifying it in TrustedUserCAKeys or in authorized_keys as @cert-authority. This CA signs the certificates, which contain the public keys of the owners, but they still need to use the private key to provide the signature, which you verify with public key from that signed certificate. If we would not have the step of signing, it authentication would be replayable and not secure at all. The trust is what you write in your configuration files, transitively you trust all the keys that were signed by the CA (indeed, can be limited by principals). > That could - as I have - be misunderstood, which I will explain later. > > > To make it clear - the unsigned public key should not be needed. But > > the private key is absolutely required. Anybody holding the public > > key would be able to impersonate you otherwise. > > Thank you for clarifying that reasoning, I only now understand my error. > With the trust relationship worded as in the the ssh-keygen(1) man page > ("only"), I imagined "sealed box signing > mechanisms", where _noone_ has access to the private key of the CA > certificate and thus only the sealed box could impersonate, which it won't. I think this does not contradict. It is up to the implementation how the CA is protected (either by sealing it into offline box, HSM, or just keeping it as online service behind some other authentication method). > Giving _actual persons_ access to the CA keys completely escaped my notice, > even as it is, when I now think about it, probably the default case. > > Could you please consider dropping a line in the documentation elaborating > that 1) "key signing is not separate, but only extends", because 2) > otherwise anyone with access to the CA keys, which per > default perspective is a human operator, could impersonate? If anyone gets access to any CA keys to use them, you are screwed. That is no different for any other CA keys in any other cryptosystem. From my POV, this is already in the definition of CA. But feel free to propose better wording if the current is confusing for you. Ideally in the openssh bugzilla: https://bugzilla.mindrot.org/ > Perhaps it would > be helpful to describe how to pass private and signed public keys with `ssh > -i ... -i ...` when having keys with or non-default names or locations? I think this is specified in manual page for ssh, in the description of the -i switch. > In any case, the last explanation has been extremely helpful, thank you very > much. You are welcome. |