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@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
