Adding an SSH key to GitHub or GitLab is the same idea as adding it to a server: the public half goes on their side, the private half stays on yours. The only difference is you paste it into a settings page instead of running ssh-copy-id. If you are still getting started with Git, this is the one-time setup that stops every clone, pull, and push from asking for credentials.
Copy your public key
You need an SSH key first. Copy the public half to the clipboard:
Pick your OS to get the right clipboard command.
xclip -sel clip < ~/.ssh/id_ed25519.pub # or: wl-copy < ~/.ssh/id_ed25519.pubIf those tools are not installed, just cat ~/.ssh/id_ed25519.pub and copy the single line by hand. It starts with ssh-ed25519 and ends with your comment.
Paste it into the web UI
- GitHub: Settings, then SSH and GPG keys, then New SSH key. Give it a title (the machine name is useful), leave the type as Authentication Key, paste, and save.
- GitLab: Preferences, then SSH Keys, then Add new key. Paste, optionally set an expiry, and save.
You are pasting the contents of the .pub file. Never paste the private key (the file with no extension).
Test it from the terminal
This is the step people skip and then wonder why git push still fails:
# GitHub
ssh -T git@github.com
# GitLab
ssh -T git@gitlab.com

GitHub replies Hi USERNAME! You've successfully authenticated, but GitHub does not provide shell access. That sentence is success, not an error. GitLab says Welcome to GitLab, @USERNAME!. The first time you connect you will be asked to trust the host key; type yes. If instead ssh -T fails to authenticate, work through Permission denied (publickey) before touching anything else. The same rejection on a plain server login (not just GitHub) has its own broader checklist in fixing SSH "Permission denied (publickey)", covering agent state, the wrong identity file, and server-side authorized_keys permissions.
Use SSH for the remote, not HTTPS
A key only helps if the repo uses the SSH remote URL (git@...), not HTTPS. If you are weighing using an SSH remote instead of HTTPS, the short version is that SSH leans on the key you just added so nothing prompts you again:
# Check the current remote
git remote -v
# Switch an existing repo from HTTPS to SSH
git remote set-url origin git@github.com:owner/repo.gitClone with the SSH URL from the start (the green Code button, SSH tab) and git clone, pull, and push use the key automatically with no prompts.
FAQ
The repo is using the HTTPS remote, which ignores SSH keys. Check with git remote -v; if it shows https://github.com/..., switch it: git remote set-url origin git@github.com:owner/repo.git. SSH keys only apply to git@ remotes. For the background, see why Git asks for a password and how SSH stops it.
It means success. GitHub authenticated your key but, unlike a real server, it does not give you a login shell, only git operations. Seeing Hi USERNAME! confirms the key is registered and working.
Yes. The same public key can be added to as many services and servers as you like. If you prefer separate keys per service, bind each to its host in ~/.ssh/config; see using multiple SSH keys.
No. SSH keys and HTTPS tokens are two separate auth methods for git. If you push over SSH (git@ remote) with a registered key, you do not need a personal access token at all.
See also
- How to Create an SSH Key in 2026: generate the key you are pasting here.
- Add an SSH key to a server: the same public key, on a server via ssh-copy-id.
- Use multiple SSH keys with ~/.ssh/config: separate work and personal keys per host.
- SSH Cheat Sheet: the full SSH reference.
Sources
Authoritative references this article was fact-checked against.
- Adding a new SSH key to your GitHub account (GitHub Docs)docs.github.com
- Use SSH keys to communicate with GitLab (GitLab Docs)docs.gitlab.com





