bobveznat
commented
8 years ago Hello and thanks for the comments. I think there may have been a subtle misunderstanding created by the documentation somewhere. Perhaps you can help me fix it.
The general premise to ssh cert authority is that the secret used to sign certificates for logging in to hosts is tightly guarded and known to few, if any, people. When a user requests a certificate we require a strong form of authentication to request a cert and when another user signs (or gives a +1 to that request) we also require a strong form of authentication. It is this strong authentication that I think has caused confusion.
The strong form of authentication is actually a user's ability to sign their own certificate using their own personal key (not a shared key). This self-signed certificate is passed to ssh-cert-authority where it is inspected. The certificate is treated as nothing more than a request and only after receiving the requisite number of +1s is the certificate signed, automatically, by ssh-cert-authority using the actual certificate authority key.
Today, in its current implementation and in a recommended deployment, this secret (the certificate authority key) is loaded into ssh-agent on a host that very few people have access to. This could very easily be a secret that is instead created in an HSM or a key in Amazon's KMS, however, ssh-cert-authority does not support that at this moment.
I'll try to summarize: users sign their own certificates using their own private keys only to verify that the requests being made to ssh-cert-authority are valid. The actual key used for signing certs that users can then use to login to hosts is stored independently of any user keys and is typically known to a very small number of people.
As an example, at my employer, there are several dozen users and signers configured in ssh-cert-authority however only 3 people (security operations staff) have the ability to bootstrap the system by loading the CA secret into ssh-agent on a host that is dedicated to running ssh-cert-authority. In this world, out of dozens of people, only 3 are able to maliciously generate certificates without an audit trail created by ssh-cert-authority (other audit trails are left behind by the user using that certificate).
Please let me know if that addresses your question. I'm pretty sure the docs simply created some confusion and I'd be delighted to look at a pull request that tries to clarify the docs.
galaxy4public
I read through the provided documentation and the more I read the more I became unsure that the original problem is solved by this project.
The line that says that signers should have CA private key on their keychain and that the service provided by this project does not have access to private keys means that one with the CA private key (one of the signers) can simply sign anything without any need to use the service.
This brings a question of the goal of this project and what the project tries to solve. Is it just some convenient way to distribute public keys for signing? If so, this approach with multiple people having access to the CA private key stands against good security practices since it would be impossible to detect who actually signed the key used for malicious activity on the server (all in all, all signers are using the same CA private key).
A much better approach would have been if the signing entity was behind the ss-cert-authority and would not be accessible to anyone directly, but through your service only. Then if the proper authorisation was implemented (e.g. through the list of fingerprints who allowed to approve the signing of the request) the signing entity (e.g. implemented via HSM or something like that) would sign the request.