How to Sync SSH Keys Across Machines Without Compromising Security

You generate an SSH key pair on your primary laptop. You add the public key to GitHub, your staging server, and a handful of cloud instances. Everything works. Then you sit down at your work desktop — or a new MacBook — and you are locked out of everything.

The common workarounds are all bad. Copying keys via USB drive means an unencrypted private key sitting on a physical device you could lose. Emailing them to yourself puts your private key in plaintext on Google's servers, your company's email archive, and every device where that email syncs. Pasting them into Slack is even worse — those messages are searchable, retained, and accessible to every workspace admin.

You could generate a new key pair on each machine and add every public key to every server. That works until you have three laptops, a desktop, and a cloud dev box. Now you are managing fifteen authorized_keys entries across five servers, and revoking access for a single machine means tracking down which key belongs to which device.

Some developers put their entire ~/.ssh directory in a dotfiles repo. This is a serious security mistake, even in a private repository. Git stores every version of every file forever. If your private key is committed even once, it exists in the repository history permanently. Running git rm only removes it from the working tree — the blob remains in the object store.

Private repositories are not as private as they seem. Anyone with read access — current teammates, CI systems, future employees — can clone the repo and extract every SSH key you have ever committed. A single compromised account with repo access exposes every key in history.

ConfigSync treats SSH keys as a first-class module. When you add the SSH module, it auto-detects your key pairs, config file, and known_hosts. Private keys are encrypted with AES-256-GCM before they leave your machine. Public keys are synced unencrypted since they are designed to be shared.

The module intelligently classifies each file. Private keys and your SSH config (which may contain hostnames, usernames, and proxy commands) are encrypted. Public keys and known_hosts are synced in plaintext because they contain no secrets.

Once the module is added, syncing SSH keys follows the same push/pull workflow as everything else in ConfigSync:

File permissions are critical for SSH. OpenSSH refuses to use a private key with permissions more permissive than 0600. ConfigSync restores private keys to 0600 and public keys to 0644 automatically, so your keys work immediately after pulling.

When you rotate SSH keys — whether on a schedule or because a key was compromised — the workflow is straightforward. Generate your new keys, then push. ConfigSync's snapshot history retains previous versions, so you can roll back if needed.

Old key versions remain in your encrypted snapshot history. If you need to access a server that still has the old public key authorized, you can restore a previous snapshot while you update the server-side authorized_keys.

Different machines often need slightly different SSH configurations. Your work laptop routes through a corporate proxy, your home machine connects directly, and your cloud dev box uses different identity files. ConfigSync supports template variables in SSH config:

Template variables are resolved at pull time, so a single SSH config file adapts to each machine's network environment. The template itself is encrypted and synced; the variable values are stored locally on each machine.

SSH keys grant access to your servers, your repositories, and your infrastructure. They deserve better than being pasted into chat messages or copied onto USB drives. ConfigSync gives you a secure, repeatable workflow: encrypt locally, sync through the cloud, decrypt on authorized machines, and restore with correct permissions every time.