Configuring a Git SSH key means generating a public/private key pair and telling both Git and your hosting provider to authenticate with it, giving you secure, password-free access to your repositories. Done correctly, it is more convenient and more secure than typing a password or juggling personal access tokens for every clone and push. Done carelessly, an unprotected private key sitting on a laptop is a credential an attacker would love to find. This guide walks through the setup and, just as importantly, the practices that keep that key from becoming a liability.
Why SSH keys instead of passwords
SSH key authentication uses asymmetric cryptography. You hold a private key that never leaves your machine, and you register the matching public key with the Git host. When you connect, the server challenges you and your client proves possession of the private key without ever transmitting it. Nothing reusable crosses the wire, which is why key auth resists the credential-replay and phishing problems that plague passwords.
For Git specifically, this means no password prompt on every operation and no long-lived token pasted into a config file. The trade-off is that you are now responsible for protecting the private key, and that responsibility is the whole security story.
Generate a modern key
Use Ed25519. It is fast, produces short keys, and is the current recommended algorithm. Only fall back to RSA (at 4096 bits) if you must talk to an old system that does not support Ed25519.
ssh-keygen -t ed25519 -C "you@example.com"
When prompted, accept the default path (~/.ssh/id_ed25519) or give the key a descriptive name if you keep several. Then the part people skip and should not:
Set a passphrase. The prompt for a passphrase is not optional theater. It encrypts the private key on disk. If your laptop is lost or its filesystem is read by malware, a passphrase-protected key is useless to whoever has it, while an unprotected key is an instant login to every repository you can reach. Choose a strong passphrase and let your agent cache it so you are not typing it constantly.
This produces two files: id_ed25519 (the private key, which never leaves the machine and is never shared) and id_ed25519.pub (the public key, which you register with the host).
Load the key into the agent
The SSH agent holds your decrypted key in memory so you enter the passphrase once per session rather than per command.
eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519
On macOS, add it to the keychain so it loads automatically:
ssh-add --apple-use-keychain ~/.ssh/id_ed25519
Register the public key with your Git host
Copy the public key, only the .pub file, never the private one:
cat ~/.ssh/id_ed25519.pub
Paste it into your provider's SSH key settings (GitHub, GitLab, Bitbucket, and Azure DevOps all have an SSH-keys section under account settings). Then verify the connection:
ssh -T git@github.com
A greeting that names your account means the key works. From here, clone with the SSH URL (git@github.com:org/repo.git) rather than HTTPS, and Git uses the key automatically.
Use SSH config for multiple keys
If you have separate keys for work and personal accounts, or per-host keys, an ~/.ssh/config file keeps them organized and is a good hardening move in its own right:
Host github.com
HostName github.com
User git
IdentityFile ~/.ssh/id_ed25519
IdentitiesOnly yes
Host gitlab-work
HostName gitlab.com
User git
IdentityFile ~/.ssh/id_ed25519_work
IdentitiesOnly yes
IdentitiesOnly yes matters: without it, the agent offers every key it holds, which can lock you out after too many failed attempts and leaks which keys you have. With it, the client offers only the key you specified for that host.
Signing commits, and where Git config comes in
The name of this topic is "git config ssh key," and there is a genuine Git config angle beyond authentication: since Git 2.34 you can sign commits with your SSH key instead of GPG. This proves a commit really came from you, which matters for supply-chain integrity.
git config --global gpg.format ssh
git config --global user.signingkey ~/.ssh/id_ed25519.pub
git config --global commit.gpgsign true
Register the same public key as a signing key with your host, and your commits show as verified. In a world where commit tampering is a real supply-chain vector, verified authorship is cheap assurance.
Key management: the part that actually protects you
Generating the key is five minutes. Managing it well is what keeps you safe:
- Never share or commit the private key. Add key files to your global gitignore and audit repos for accidentally committed keys. A private key in a public repo is a full compromise.
- One key per device. Do not copy a private key between machines. Generate a separate key on each device so you can revoke one without disrupting the others.
- Rotate and revoke. When a laptop is decommissioned, lost, or an employee leaves, remove the corresponding public key from every host immediately. Rotate keys periodically as a matter of hygiene.
- Protect the whole chain, not just the key. A leaked private key is one path to compromise; a malicious dependency in your build is another. If your pipeline handles credentials or signs artifacts, treat the supply chain as part of the same threat model, an SCA tool such as Safeguard can flag when a build pulls in a known-vulnerable component that could be positioned to exfiltrate secrets.
The Academy has more on securing developer workflows end to end.
FAQ
Should I set a passphrase on my SSH key?
Yes. The passphrase encrypts the private key on disk, so a lost or stolen laptop does not hand an attacker working credentials. Use the SSH agent to cache it so you only enter it once per session, keeping the security without the friction.
Ed25519 or RSA for Git?
Use Ed25519. It is fast, secure, and produces compact keys, and it is the current recommendation. Choose RSA at 4096 bits only when you must connect to a legacy system that does not support Ed25519.
Which key do I give to GitHub?
Only the public key, the .pub file. The private key never leaves your machine and is never uploaded or shared. If you ever pasted a private key into a settings box, treat it as compromised and rotate it.
Can I use one SSH key on all my devices?
It is better not to. Generate a separate key per device so that losing one machine lets you revoke just that key without disrupting your other machines. Copying private keys around multiplies the places a single leak can come from.