Also provide units to renew ssh certificates
Those are based on the cert-renewer unit files but adapted for ssh certificates
the target file allows you to easily stop/restart/disable all instances.
@tashian Can you take a look to this?
Hi @darix, this is ready to merge. Could you please sign our CLA so we can accept this PR?
Thank you for your contribution to the project. :D
@darix Although contributions to an Apache 2 software might not require a CLA, see this blog post. We can merge this right away if you sign it, so we don't need to look into other implications, although in this case, I don't see any. So can you sign it?
@tashian is this still ok? Is there any update you can do to our current scripts that will avoid the need of merging this?
sorry for the delay. signed now.
I just noticed that this merge request was modified before the merge. I would like to understand the reasoning to only want to support ed25519 keys.
@tashian any reason for hardcoding ed25519 key?
- CERT_LOCATION=/etc/ssh/ssh_host_%i_key-cert.pub \
- KEY_LOCATION=/etc/ssh/ssh_host_%i_key
+ CERT_LOCATION=/etc/ssh/ssh_host_ed25519_key-cert.pub \
+ KEY_LOCATION=/etc/ssh/ssh_host_ed25519_key
and pardon my ignorance, how is %i populated?
if you have a service like [email protected] you can start the service with systemctl start foo@bar
then %i has the value bar.
long version here: https://0pointer.de/blog/projects/instances.html
@darix sure, here's the reasoning for my hard coding of the Ed25519 key:
https://github.com/smallstep/cli/pull/657#discussion_r836879508
In short, I don't feel it's worth the added complexity of a systemd template to cover more than one host key type.