Hi,
spurred by a severe mistunderstanding on my part, I found myself in a
very OSI-8/PEBCAC situation. I would like to politely suggest two
hopefully small alterations to make such misunderstandings more
difficult and stop a misguided user much earlier. Please bear with my
explanation, I try to be brief.
My problem's root cause was that misunderstood what a ssh certificate
actually is. Instead of staying with the concept "certificate"
consisting of a public part and a key, signed by some authority or
oneself (yes, that is how the word certificate is normally used), I
mistook the signed public key for something alike to a token, which
would _replace instead of extend_ the public/private key pair.
That I managed to confuse these two concepts is entirely my own fault,
having worked with token-based systems, I fear I fell into the "have a
hammer, everything is a nail" trap. Once I fell into it, however, I
felt encouraged by the behaviour of `ssh` and parts of the man pages,
which I would like to suggest to change.
First, it is actually possible to pass the certificate, which is the
signed public key, with the switch `-i`. From the perspective of my
misunderstanding, that made perfect sense, because, when thinking of a
token, that token is a secret corresponding to the private part of the
key.
When calling `ssh -i <pub-signed>` and when key pairs from default
locations are used to have the public part signed, the corresponding
private key is still used and the login succeeds without any notice
that the user is doing something wrong. Only with other, different
keypairs, the login errors (missing the private key, as I now
understand) with "Load key <path>: invalid format".
If possible (that's breaking), I would like to suggest to alter the
behaviour of `ssh` to outright refuse to accept anything which is not
a secret key on `-i` and to substitute the "invalid format" message
with "<path> is not a private key". If that is considered to harsh, I
would like to ask for a warning with a message as above instead of ssh
silently succeeding with a login.
The second change I would like to suggest concerns the man page
SSH-KEYGEN(1). There the section CERTIFICATES states that
> [...] Certificates consist of a public key, some identity
> information, zero or more principal (user or host) names and a set
> of options that are signed by a Certification Authority (CA) key.
> Clients or servers may then trust only the CA key and verify its
> signature on a certificate rather than trusting many user/host keys.
The wording "only the CA key [...] rather than" reinforced my
misunderstanding that the secret part is replaced. I would like to
suggest to rephrase that line to state something like
"In an otherwise normal public/private key pair exchange, clients or
servers may then trust any public key, provided it has been signed by a
trusted CA, and verify it's signature on a certificate fingerprint,
instead of trusting a set of individual user/host keys configured on a
single host."
I believe with these changes, a misguided user would be stopped much
earlier and, equipped with clearer error or warning messages, would
graps conceptual misunderstandings faster.
Thank you for your patience and consideration. Cheers,
--
Christopher
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
spurred by a severe mistunderstanding on my part, I found myself in a
very OSI-8/PEBCAC situation. I would like to politely suggest two
hopefully small alterations to make such misunderstandings more
difficult and stop a misguided user much earlier. Please bear with my
explanation, I try to be brief.
My problem's root cause was that misunderstood what a ssh certificate
actually is. Instead of staying with the concept "certificate"
consisting of a public part and a key, signed by some authority or
oneself (yes, that is how the word certificate is normally used), I
mistook the signed public key for something alike to a token, which
would _replace instead of extend_ the public/private key pair.
That I managed to confuse these two concepts is entirely my own fault,
having worked with token-based systems, I fear I fell into the "have a
hammer, everything is a nail" trap. Once I fell into it, however, I
felt encouraged by the behaviour of `ssh` and parts of the man pages,
which I would like to suggest to change.
First, it is actually possible to pass the certificate, which is the
signed public key, with the switch `-i`. From the perspective of my
misunderstanding, that made perfect sense, because, when thinking of a
token, that token is a secret corresponding to the private part of the
key.
When calling `ssh -i <pub-signed>` and when key pairs from default
locations are used to have the public part signed, the corresponding
private key is still used and the login succeeds without any notice
that the user is doing something wrong. Only with other, different
keypairs, the login errors (missing the private key, as I now
understand) with "Load key <path>: invalid format".
If possible (that's breaking), I would like to suggest to alter the
behaviour of `ssh` to outright refuse to accept anything which is not
a secret key on `-i` and to substitute the "invalid format" message
with "<path> is not a private key". If that is considered to harsh, I
would like to ask for a warning with a message as above instead of ssh
silently succeeding with a login.
The second change I would like to suggest concerns the man page
SSH-KEYGEN(1). There the section CERTIFICATES states that
> [...] Certificates consist of a public key, some identity
> information, zero or more principal (user or host) names and a set
> of options that are signed by a Certification Authority (CA) key.
> Clients or servers may then trust only the CA key and verify its
> signature on a certificate rather than trusting many user/host keys.
The wording "only the CA key [...] rather than" reinforced my
misunderstanding that the secret part is replaced. I would like to
suggest to rephrase that line to state something like
"In an otherwise normal public/private key pair exchange, clients or
servers may then trust any public key, provided it has been signed by a
trusted CA, and verify it's signature on a certificate fingerprint,
instead of trusting a set of individual user/host keys configured on a
single host."
I believe with these changes, a misguided user would be stopped much
earlier and, equipped with clearer error or warning messages, would
graps conceptual misunderstandings faster.
Thank you for your patience and consideration. Cheers,
--
Christopher
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev