GuideAugust 18, 20266 min read

Managing SSH Configs for 50+ Servers

Jump hosts, per-host keys, proxy commands — large SSH configs are complex and painful to recreate. Here is how to keep them synced, encrypted, and consistent.

SSH Config at Scale

A simple SSH config with three servers is easy to manage. But infrastructure grows. Before long you have staging clusters, production bastion hosts, client environments, CI runners, and personal servers. Your ~/.ssh/config file is 200+ lines with jump host chains, per-host identity files, and proxy commands that took months to refine.

Recreating this on a new machine is painful. One wrong hostname, one missing key, and you cannot reach the server you need during a production incident. ConfigSync keeps your entire SSH setup synced and encrypted across every machine.

The SSH Module

ConfigSync's built-in SSH module tracks your entire ~/.ssh/ directory. Private keys are encrypted automatically. Config files and public keys sync in plaintext. File permissions are preserved on pull:

What the SSH module captures
configsync scan # ✓ Detected ssh module: # ~/.ssh/config (synced, plaintext) # ~/.ssh/known_hosts (synced, plaintext) # ~/.ssh/id_ed25519 (synced, encrypted) # ~/.ssh/id_ed25519.pub (synced, plaintext) # ~/.ssh/work_rsa (synced, encrypted) # ~/.ssh/work_rsa.pub (synced, plaintext) # ~/.ssh/deploy_key (synced, encrypted) # File permissions preserved: keys=600, directory=700
Automatic permission handling: SSH refuses to use keys with incorrect permissions. ConfigSync restores 600 on private keys and 700 on the .ssh directory after every pull.

Template Variables for Jump Hosts

When your SSH config references environment-specific hosts like bastion servers, use template variables to avoid maintaining separate config files:

~/.ssh/config with template variables
Host staging-* User deploy ProxyJump {{vars.bastion_host}} IdentityFile ~/.ssh/work_rsa Host prod-* User deploy ProxyJump {{vars.prod_bastion}} IdentityFile ~/.ssh/work_rsa StrictHostKeyChecking yes Host *.internal User admin ProxyJump {{vars.bastion_host}} IdentityFile ~/.ssh/work_rsa Host personal-* User sean IdentityFile ~/.ssh/id_ed25519
Variable definitions in config.yaml
profiles: work: vars: bastion_host: "bastion.corp.example.com" prod_bastion: "prod-jump.corp.example.com" personal: vars: bastion_host: "jump.myhomelab.dev" prod_bastion: "jump.myhomelab.dev"

Pull with --profile work and the bastion hosts resolve to corporate infrastructure. Switch to --profile personal and they point to your own servers. One SSH config, multiple environments.

Profile-Based SSH Configurations

Beyond variable substitution, profiles let you maintain entirely different SSH configurations for different contexts:

Profile-specific SSH management
# At work: corporate keys and full jump host chain configsync pull --profile work # Pulls: work_rsa, deploy_key, corporate SSH config # At home: personal keys only configsync pull --profile personal # Pulls: id_ed25519, personal SSH config # On a shared machine: minimal access configsync pull --filter modules:ssh --profile minimal # Pulls only what you need for this session

This is particularly useful when you have client-specific SSH keys. A consulting developer might have separate keys for each client, pulled only when working in that client's profile.

Syncing known_hosts to Avoid TOFU Prompts

The known_hosts file stores fingerprints of servers you have connected to before. Without it, SSH prompts "Are you sure you want to continue connecting?" for every server on every new machine. When you manage 50+ servers, that is 50+ prompts you have to manually accept.

ConfigSync syncs your known_hosts file so verified fingerprints carry over to new machines. Your second laptop immediately trusts every server your first laptop has connected to. This is not just a convenience — it eliminates the security risk of developers blindly typing "yes" to Trust On First Use prompts.

The Complete SSH Workflow

With ConfigSync managing your SSH configuration, adding a new server follows a simple flow: configure the host block on one machine, connect to verify the fingerprint, push your updated config, and every other machine has the new server available on the next pull. Key rotation follows the same pattern: generate the new key, update config, push, and all machines get the update simultaneously.

No more SCP-ing keys between machines. No more hand-editing config files on each laptop. Your SSH setup is version-controlled, encrypted, and always in sync.

Ready to try ConfigSync?

Sync your entire dev environment across machines in minutes. Free forever for up to 3 devices.

Get StartedRead the Docs