17

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.

top 15 comments
sorted by: hot top controversial new old
[-] AbidanYre@lemmy.world 5 points 5 months ago
[-] mmmac@lemmy.zip 1 points 5 months ago

Welp time to add this to the backlog of things I wanna do

[-] cmnybo@discuss.tchncs.de 1 points 5 months ago

So what happens when the certificate expires? Do you get locked out if you don't have physical access?

[-] non_burglar@lemmy.world 3 points 5 months ago

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.

[-] AbidanYre@lemmy.world 0 points 5 months ago* (last edited 5 months ago)

Like the other commenter said, they're expiring regularly. Host keys expire ~monthly and there's a cronjob to reach out to the certificate authority server to renew them. User certs expire ~daily and the first time I ssh on any given day I have to authenticate with the CA. Recently tied it to PocketID for SSO.

[-] Anekdoteles@feddit.org 0 points 5 months ago

Sooo, CA unreachable means connection dead, which is a manageable risk. But giving a third party the authority over my SSH access sounds like a great way to make it convenient for state actors to invade my privacy.

[-] AbidanYre@lemmy.world 1 points 5 months ago

I mean, the CA is also self hosted so I'm not sure what you think the extra attack vector is here.

[-] Tabula_stercore@lemmy.world 4 points 5 months ago

Trategie is vulnerable and deprecated. You might want to try its secure successor Strategie

[-] solrize@lemmy.ml 3 points 5 months ago

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.

[-] 4am@lemmy.zip 2 points 5 months ago

nix for local machine config, Terraform for VM wrangling, and Ansible to orchestrate it all

[-] amateurcrastinator@lemmy.world 1 points 5 months ago

Can you expand a little bit on that please?

[-] B0rax@feddit.org 1 points 5 months ago

Man, I really need to learn ansible…

[-] slazer2au@lemmy.world 1 points 5 months ago

Learn Linux TV on YouTube has an awesome series on it.

[-] notabot@piefed.social 0 points 5 months ago

The general process would look something like:

  1. Find all of the SSH keys you want to replace.
  2. For each of thise keys, identify everywhere you use it to authenticate, and write this down! This list will form the basis of the rest of the plan. Make sure you list all of the accounts/servers you log in to, and don't forget things like github or other external systems if you use them.

You'll need to perform the following steps for each SSH key you are replacing:

  1. Rename the public and private keys to something like old_id_rsa and old_id_rsa.pub (obviously use the same type name as your key, just prefix old_)
  2. In your ~/.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)
  3. Check you can still log in to the servers you could log in to before. It should still be using the old key, just with a different filename, so it should still work.
  4. Generate your new SSH keys ssh-keygen -t ed25519
  5. Log in to each server and ADD the new ~/.ssh/id_ed25519.pub key to the authorized_keys file or equivalent mechanism. Do not remove the old public key yet.
  6. Remove the IdentityFile line from your ~/.ssh/config
  7. Check you can log in to all your systems. This will validate that your new key is working.
  8. Remove your old public key from the authorized_keys file 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 ansible if it'll be a regular job.

[-] non_burglar@lemmy.world 1 points 5 months ago
  1. Find all of the SSH keys you want to replace.

I hate this part.

this post was submitted on 21 Dec 2025
17 points (100.0% liked)

Selfhosted

59651 readers
190 users here now

A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.

Rules:

  1. Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.

  2. No spam posting.

  3. Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.

  4. Don't duplicate the full text of your blog or github here. Just post the link for folks to click.

  5. Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).

  6. No trolling.

  7. No low-effort posts. This is subjective and will largely be determined by the community member reports.

Resources:

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

founded 3 years ago
MODERATORS