SSH & Keys

Git SSH Config Generator

Git SSH Config

Build Your SSH Config

Create a secure .ssh/config file to manage SSH keys and authentication for one or more remote Git repositories. Follow the steps below to add your hosts and generate a ready-to-use config file.

Step 1: Add Git Hosts

For each remote Git repository, enter a unique Host alias (e.g., github-work), the HostName (e.g., github.com), your SSH User (usually git), and the path to your IdentityFile (private key). You can add multiple hosts for different repos or services.

How to Use Your SSH Config for Git

  • Place the generated config file in your ~/.ssh/ directory.
  • Set correct permissions: chmod 600 ~/.ssh/config
  • Use the Host alias in your git remote URL, e.g., git@github-work:username/repo.git
  • Each host entry can use a different SSH key for different GitHub, GitLab, Bitbucket, or private servers.
  • Never share your private keys. Keep your .ssh/config and keys secure.

Frequently Asked Questions

The .ssh/config file lets you define settings for connecting to remote servers via SSH, including aliases, keys, and options. For Git, it helps you manage multiple accounts or keys easily.

Add a Host entry for each remote (e.g., github-work, github-personal) with its own IdentityFile. Use the Host alias in your git remote URL instead of the actual hostname.

Yes. All config generation happens in your browser. No data is sent or stored anywhere. Your SSH keys and configuration remain completely private.

Set permissions to 600: chmod 600 ~/.ssh/config. This keeps your config private and secure.

Yes! You can add multiple Host entries for different Git hosting services. Each can use a different SSH key for different accounts.

Tool features

Generate SSH configuration files for Git repositories with ease and security
4 features

Guided configuration

Builds a valid ~/.ssh/config without memorising the directive names.

Multiple hosts

GitHub, GitLab and Bitbucket entries side by side in one file.

Per-account keys

Pin a different IdentityFile to each alias so accounts never collide.

Runs in your browser

The config is generated locally and never sent anywhere — and it only references key paths.

What ~/.ssh/config does & how host aliases work

Using more than one Git account from one machine

Git identifies you by SSH key, not by username — so the moment you have a work account and a personal account on the same host, you have a problem. Both want to reach git@github.com, and SSH will offer the same default key to both. The server sees one identity and pushes land under the wrong account.

A ~/.ssh/config file fixes this with host aliases. You invent a name like github-work, point it at the real HostName github.com, and pin a specific IdentityFile to it. Clone using the alias — git@github-work:org/repo.git — and SSH picks the right key every time, with no flags to remember.

Host
The alias you type in a Git remote, e.g. github-work. Purely local — it does not have to resolve in DNS.
HostName
The real server the alias points at, e.g. github.com.
User
The SSH user. For Git hosting this is almost always git, regardless of your account name.
IdentityFile
The private key to use for this alias, e.g. ~/.ssh/id_ed25519_work.

How to use this tool

Build a multi-account Git SSH config in five steps
1
Add a host entry
Give it an alias you will recognise — github-work, gitlab-personal — rather than the bare hostname, so the two never collide.
2
Point it at the real host and key
Set HostName to the actual server (github.com), leave User as git for Git hosting, and set IdentityFile to the private key for that account.
3
Repeat for each account
Add one entry per account or organisation. They can all share a HostName — it is the alias and the key that differ.
4
Save the config
Copy or download the file to ~/.ssh/config, then run chmod 600 ~/.ssh/config. SSH ignores a config file that other users can write to.
5
Use the alias in your remotes
Clone with git clone git@github-work:org/repo.git, or repoint an existing repo with git remote set-url origin git@github-work:org/repo.git.

Related tools

Keep debugging with tools from the same suite
3 tools
SSH Key Generator
Generate SSH key pairs (RSA, ECDSA, Ed25519) for secure server authentication
SSH Config Builder
Visual SSH configuration file builder for multiple hosts with advanced options
SSH Key Converter
Convert SSH keys between different formats (OpenSSH, PuTTY PPK, PEM)

Frequently asked questions

Common questions about Git SSH configuration
7 Q&A

Give each account its own key and its own host alias. Create two entries with the same HostName github.com but different aliases and IdentityFile values, then clone each repository through the matching alias. SSH selects the key from the alias, so the accounts never cross.

At ~/.ssh/config on macOS and Linux, and C:\Users\<you>\.ssh\config on Windows. Run chmod 600 ~/.ssh/config after saving — SSH ignores a config file that is writable by other users, usually without saying why.

Usually the remote still points at the real hostname rather than your alias. Check with git remote -v: it needs to read git@github-work:org/repo.git, not git@github.com:.... Another common cause is ssh-agent offering a different key first — ssh -T git@github-work will tell you which identity the server actually sees.

No. For GitHub, GitLab and Bitbucket the SSH user is always git — your identity comes from the key, not the username. Setting it to your account name is a common mistake and causes an immediate authentication failure.

No. The Host line is a local label that only your SSH client sees, so github-work or client-a is fine. The HostName line is the one that must be a real, resolvable address.

Yes. Run ssh -T git@your-alias — GitHub and GitLab both answer with the account name the key maps to, which is the quickest way to confirm the right key is being offered. Add -v to see exactly which identity files SSH tried.

No. This generator builds the config text in your browser and never transmits it — and in any case it only ever references a key path, such as ~/.ssh/id_ed25519_work. Your actual private key is not involved.