Conversation
|
|
||
| # substitute your own signing key for id_ecdsa | ||
| # substitute your own GOPATH (or add to environment) | ||
| ExecStart=/bin/bash -c "\ |
There was a problem hiding this comment.
Hey thank you for the patch here. I think there may be a more efficient way to do what you're doing here for the add. Did you see the PrivateKeyFile configuration option for signcertd? With that option you can run this like I do in the upstart example that's in here:
/usr/bin/ssh-agent $GOPATH/bin/ssh-cert-authority runserver
When run that way ssh-agent starts, sets the SSH_AUTH_SOCK to be the path to a new agent socket and then execs ssh-cert-authority. When combined with the PrivateKeyFile config option the ssh-cert-authority daemon will automatically load the private key.
You can take this even further with the encrypt-key subcommand of ssh-cert-authority if you're on Amazon. I tried to write a step by step here: https://github.com/cloudtools/ssh-cert-authority/blob/master/README.rst#encrypting-a-ca-key-using-amazons-kms
The encrypt-key suggestion won't affect this patch, decryption of the key is transparent when it's in place, that's just a runtime suggestion for you.
Moving forward with this pull request I'll request that you change to leverage PrivateKeyFile and assume that the caller is either using that or doing ssh-add themselves after the daemon starts. This is mostly because I don't want an example in the tree that suggests a user should have an unencrypted certificate authority anywhere.
Thanks again for taking the time to put this together and send the request.
There was a problem hiding this comment.
yup, makes sense. I'll fix this up to get it more in line w/ prj.
This is a sample systemd unit file I was using.
Some modification is needed. See notes inside file for enabling the service.