-
Notifications
You must be signed in to change notification settings - Fork 25
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Publish Design Doc #11
Comments
In lieu of a design doc, why include the nodes' public keys in the known_hosts files instead of single @cert-authority entry with the CA's pub key? |
Not all clients support trusting CAs, and not all servers (eg, our networking gear) support serving certificates. Since we have the information anyways, we can just put them in the known_hosts. There seems to be little harm in doing so, and it provided the lowest-risk path for us (replacing hand-crafted ssh-keyscan'd known_hosts files) Also, if you've got bash completion set up, you can tab complete hostnames. |
Seems reasonable. Perhaps we should add an option to include the CA pub key in the generated known_hosts, and a separate option to include hosts' pub keys. In the case of networking gear or other nodes where you can't run sharkey-client, do you manually insert those records into the database currently? |
Yeah, supporting multiple kinds of known_hosts generation (including ca, hosts, or both) was planned in the original design doc (just hasn't been done yet). I'll make sure there's an issue on github tracking that. Once #12 is done, we could presumably use that to manually add them, or as you said, we can manually inserting them into the database. We'd like to add an API for a "trusted 3rd party" (eg, our network device management service) to be able to add devices it manages. We'd need some ACLs around what hosts it's allowed to add, though. |
I wrote a design doc, which should be published in this repo (minus any proprietary stuff).
The text was updated successfully, but these errors were encountered: