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.
Comment on SSH Client for Linux Desktop and Android - Alternative to Termius
farcaller@fstab.sh 1 day ago
Not an answer, but I’m curious: what’s wrong with just having several ssh keys, one per device?
irotsoma@piefed.blahaj.zone 22 hours ago
needanke@feddit.org 13 hours ago
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.
needanke@feddit.org 13 hours ago
and I’d need to have password access enabled in order to add the keys
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.
suicidaleggroll@lemmy.world 21 hours ago
You can back up ~/.ssh though, and restore it on any system.
farcaller@fstab.sh 13 hours ago
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 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
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.
Also, I want a key backed up in case of disaster since all of my devices are in my home most of the time
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.
cyrl@lemmy.world 14 hours ago
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
tal@lemmy.today 1 day ago
In fact, that’s generally what you want to do, since if one device gets lost or compromised, you just revoke access to the key for that device.