• 1 Post
  • 161 Comments
Joined 7 months ago
cake
Cake day: June 4th, 2025

help-circle
  • 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.











  • Why would they add LLMs to Calibre?

    It looks like it’s so you can “discuss” a book with the overgrown autocomplete, or ask it what to read next if you are incapable of independent thought. I could, sort of, understand making a plugin for this sort of nonsense, but building it in, as a brief check of their site suggests has happened, is so utterly ridiculous that it defies rationality.

    I liked Calibre, I’ve even contributed code to it, but it looks like I’ll be investigating this fork now.


  • notabot@piefed.socialtoScience Memes@mander.xyzDo it Sasha!
    link
    fedilink
    English
    arrow-up
    3
    ·
    22 days ago

    There’s a lot of work to go around. The leopards take care of those who vote against their own interests, the tigers can deal with those who shoud be getting nothing more than a lump of coal for Christmas. In the case that both of these hold true, whichever gets to the perpetrator first eats them.







  • notabot@piefed.socialtoLinux@lemmy.mlSnapper is a lifesaver
    link
    fedilink
    English
    arrow-up
    13
    ·
    1 month ago

    This is so very important. Snapshots are very helpful tools, and most if the time they’re exactly what you need to recover. Unfortunately they don’t help when the drive fails, or the machine is destroyed by flooding, or myriad other failure modes (human error nit being the least of them). Remote backups are vital if you want your data to survive those events.

    Remote copies of the snapshots are a start, but leave you at the mercy of and bugs in the snapshot system, and usually more critically, you have to transfer the whole snapshot or delta, and can’t exclude data without first rearanging your mountpoints.

    Lical snapshots and remote file backups give you the best of both worlds, making it easy to recover your data from pretty much any event.