A few weeks ago I installed a shiny new SSH client on a fresh laptop. Before it would let me open a single terminal, it wanted an email address, a password, and permission to “keep my hosts in sync”. I closed it and went back to plain old ssh.
I am not against sync. I use it for notes, photos, half my life. But the list of servers I connect to is not a notes file. It is a map of my infrastructure. And I think most of us hand that map over without even noticing.
What a synced SSH client actually knows about you
Open your saved connections and read them like an outsider would. Every entry is a hostname or IP, a port, a username, and usually a friendly label. Labels like “prod-db-primary” or “client-x-staging” are lovely for you and just as lovely for anyone else who reads them.
Depending on the app and your settings, the synced blob can also include which key goes with which host, jump host chains, port forwards, sometimes saved passwords, and in some setups the private keys themselves. Even when the vendor encrypts all of it, you are now trusting their code, their key handling and their staff, on top of your own.
Put together, that list tells someone exactly where your servers are, which user to try, and which ones matter most. Nobody needs your password to get value out of that.
Try this once. Scroll through your saved sessions from top to bottom. For most of us it reads like a history of every project we have touched in the last few years, often including a server or two we forgot was still running. If a stranger had that list, they would know more about your setup than some of your own team.
The threat model, in plain words
I keep it to three questions.
- What if the vendor gets breached? Your host map leaves with everyone else’s. You will not get a vote on how fast they tell you.
- What if the vendor goes away, or changes the deal? Pricing changes, an acquisition, a product shut down. If your connections only live in their cloud, your workflow lives there too. Can you export everything, today, in a format another tool reads?
- What does your client or your auditor think? A lot of contracts say infrastructure details stay inside approved systems. A third party SSH sync service is rarely on that list, and “it was just the hostnames” is not a fun sentence to say in a security review.
None of this means cloud sync is evil. It means it is a decision, and it should be one you made on purpose.
The manual way still works really well
Before any app, there is ~/.ssh/config. It has been there forever, and it is honestly underrated. A clean one looks like this:
Include ~/.ssh/config.d/*
Host *
AddKeysToAgent yes
IdentitiesOnly yes
ServerAliveInterval 30
Host bastion
HostName 203.0.113.10
User sunil
IdentityFile ~/.ssh/id_ed25519_work
Host app-*
User deploy
ProxyJump bastion
IdentityFile ~/.ssh/id_ed25519_workA few habits that make it pleasant:
- Split it with Include. One file per client or project in
~/.ssh/config.d/. Put theIncludeline at the very top, because SSH uses the first value it finds for each option. When a project ends, you delete one file. - Use Host patterns.
Host app-*saves you from copying the same five lines twenty times. - One key per context, always with a passphrase.
ssh-keygen -t ed25519 -a 100 -f ~/.ssh/id_ed25519_work. Already have a key without one?ssh-keygen -p -f ~/.ssh/id_ed25519_workadds it. - Let ssh-agent remember it. With
AddKeysToAgent yesyou type the passphrase once per session, not once per connection.IdentitiesOnly yesstops SSH from offering every key you own to every server.
Then back it up, encrypted, somewhere you control. Something as simple as this is fine:
tar czf - -C ~ .ssh | gpg --symmetric --cipher-algo AES256 -o ssh-backup.tgz.gpg
Put that file on a USB stick or your normal backup drive. And please test the restore once. I wrote a whole post about backups that fail the only test that matters, and SSH keys are no exception.
When sync is genuinely worth it
Teams. The moment five people need the same forty hosts, a personal config file starts to hurt. New joiner, someone leaves, a server moves. I get why people reach for a shared cloud vault.
But there are safer shapes for this:
| What you want to share | A safer way |
|---|---|
| Host names and options | A config.d file in a private Git repo you already control. No secrets in it. |
| Access to servers | SSH certificates signed by your own CA, short lived, instead of copying keys around. |
| One way in | A bastion with ProxyJump, so only one box faces the internet. |
| The odd shared secret | Your company password manager, which already has access control and audit logs. |
Notice that in every row, the private key stays on the person’s own machine. That is the line I would not cross.
If you want a GUI without the account
Plain config files are great until you have a lot of tabs open and want SFTP in the same window. That is fair. If you want a desktop client, look for one that is local-first and tells you exactly where your data goes.
One I like is TerCTL, an open source SSH client and terminal manager built by Rakesh Modak and Sagar Sen. It needs no account and sends no telemetry. Hosts, groups and known host fingerprints sit in a local SQLite file, while passwords, passphrases and private keys go to the OS keychain (macOS Keychain, Windows Credential Manager, or Secret Service on Linux). When you want to move to a new machine, you export your setup as an encrypted file (Argon2id plus XChaCha20-Poly1305) and import it on the other side. It runs on macOS, Windows and Linux, and it is MIT licensed, so you can read the code on GitHub instead of taking anyone’s word for it.
We collect tools like this, and the thinking behind them, on our open source page.
The habit that matters
Here is my small checklist. Can you list where your host list lives right now? Does every private key have a passphrase? Is there an encrypted backup you have actually restored? And if your SSH app vanished tomorrow, could you still reach every server by lunch?
If yes, you are fine, whatever you use. Use whatever you like, the habit matters more than the tool.
