Selfhosted
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:
-
Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
-
No spam posting.
-
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.
-
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
-
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
-
No trolling.
-
No low-effort posts. This is subjective and will largely be determined by the community member reports.
Resources:
- selfh.st Newsletter and index of selfhosted software and apps
- awesome-selfhosted software
- awesome-sysadmin resources
- Self-Hosted Podcast from Jupiter Broadcasting
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
view the rest of the comments
The primary issue is I don't always access devices from only those 3 systems. If I'm traveling or I wipe my device or get a new one, I would have to add the new key to many servers as authorized keys, and I'd need to have password access enabled in order to add the keys in the first place. Also, I want a key backed up in case of disaster since all of my devices are in my home most of the time. A few people use these systems, but only I maintain them.
For that scenario you could also consider using certificate based login. Just store your root certificate in a safe place (like a Keepass) an then sign new keys for your new devices when you get one.
https://docs.ssh.com/manuals/server-admin/44/User_Authentication_with_Certificates.html
Besides the other points, you could just add the public keys directly in the .ssh/authorized_keys(2) file of the server as long as you still have access from another device. That way you don't have to enable passwords.
Let's untangle those problems. I have a similar setup so I just want to share some ideas to show that you don’t need to copy keys.
If you oftentimes access ssh from untrusted systems you’re kind of in a bad spot to begin with. The best thing you can have is a yubikey on a keychain. Everything else means you leak secret material (a password or a key) to a machine you don’t inherently trust.
Again, something that you can easily solve with a hardware key [in a safe]. But realistically, in case of a disaster a local shell password login should be good enough?
I'd recommend you to think about what attacks are you trying to prevent by using a shared private key. I’m not saying it's a bad concept, inherently having it in your password manager (like 1Password that even has ssh-agent support) is pretty common. The problem with just the keys is that it's non-trivial to expire them if needed. You might be indeed better off with some web based authentication that you can access from any place which would ask you secret questions/send you a text message or do whatever 2FA you deem sufficient and mint you a short-lived certificate for ssh.
You can store an ssh key in Bitwarden or Keepass(XC) easily enough - Bitearden can certainly be configured as the actual source of your ssh keys with only a tiny bit of config effort
You can back up ~/.ssh though, and restore it on any system.