What is the best trategie to refresh ssh keys?
from ratatouille@feddit.org to selfhosted@lemmy.world on 21 Dec 23:52
https://feddit.org/post/23282968
from ratatouille@feddit.org to selfhosted@lemmy.world on 21 Dec 23:52
https://feddit.org/post/23282968
My ssh keys are oldMany times I had the Idea to replace them and cleanup. Put the approach feels old not intuitive and i’m affraid of problems.
How do you manage keys and get sure they do ot get to old.
#selfhosted
threaded - newest
Do you think they are compromised? Generally you have to invalidate the public keys in any .ssh_hosts file that accepts them, and create new ones instead. I generally install .ssh_hosts on remote machines using an ansible playbook. I don’t have any automation to cycle them but I guess I would also do that with ansible if I thought it were needed.
Ansible may be old school by now, but it works for me. Maybe the cool kids are using something newer now. I want to look into nix or guix one of these days.
nix for local machine config, Terraform for VM wrangling, and Ansible to orchestrate it all
Man, I really need to learn ansible…
Learn Linux TV on YouTube has an awesome series on it.
Ansible is not old-school. Shame on the person telling you that.
The general process would look something like:
You’ll need to perform the following steps for each SSH key you are replacing:
old_id_rsaandold_id_rsa.pub(obviously use the same type name as your key, just prefixold_)~/.ssh/config, add a line telling SSH to use the old key as well as the new ones:IdentityFile ~/.ssh/old_id_rsa(change the key filename as aporopriate)ssh-keygen -t ed25519~/.ssh/id_ed25519.pubkey to theauthorized_keysfile or equivalent mechanism. Do not remove the old public key yet.IdentityFileline from your~/.ssh/configauthorized_keysfile on each server you log in to.Depending on your threat model you’re going to want to do this more or less often, and so you may want to consider automating it with sonething like
ansibleif it’ll be a regular job.I hate this part.
This generally referred to as Key Rotation. It applies to everything from SSH keys, to API keys in running apps.
There are automated ways to do this with ease, but it’s very simple to do with a single script, and some sort of secure key/value store (bitwarden, Vault, etcd…whatever).
The process is basically something like:
/ssh_keys/host1-private-12.1.25and/ssh_keys/host1-public-12.1.25/ssh_keys/host1-private-12.21.25and/ssh_keys/host1-pub-12.21.25/ssh_keys/host1-private-currentYour script can clear the old keys if needed but simply validating them in the access change serves the same effect. Up to you.
I moved over to certificates a while ago.
smallstep.com/blog/use-ssh-certificates/
So what happens when the certificate expires? Do you get locked out if you don’t have physical access?
Re-gen the keys. In this environment, you would have PKI setup and automation to handle cert renewal.
Having the certs expire is an advantage, security-wise. Auth will expire with certs, stolen creds can be instantly invalidated.
That’s a really interesting read, thanks for sharing
The best way is to use ssh-ca and certificate based auth.