I’ve been using Termius for a few years for an SSH client. Have have a lot of self-hosted servers both in my home lab and on VPSs. I’m looking to cut some costs since it’s $120/year and really the main thing I use it for is syncing my SSH accounts and credentials between a laptop, a desktop, and my Android phone. So I’m looking for a new method to sync these things.
I’d prefer a single application, but I’d settle for a good, secure way to sync the credentials and recommendations for applications on Fedora and Android.
Edit: I’m OK with a one time payment application, but prefer open source or a solution I can self-host the sync server. And I don’t want a subscription.
Not an answer, but I’m curious: what’s wrong with just having several ssh keys, one per device?
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.
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.