SSH Keys for GitHub and GitLab: Setup and Test (2026)

Setting up SSH keys for GitHub and GitLab is a rite of passage that unlocks a world of seamless, password-less Git operations, but most people get tripped up by the subtle differences in how each platform expects your keys to be registered.

Let’s see this in action. Imagine you’ve just generated a new SSH key pair. Your command line might look something like this:

ssh-keygen -t ed25519 -C "your_email@example.com"

This spits out two files: id_ed25519 (your private key) and id_ed25519.pub (your public key).

Now, to add this to GitHub:

1. Go to GitHub’s website.
2. Click your profile picture in the upper-right corner.
3. Select "Settings."
4. In the left sidebar, click "SSH and GPG keys."
5. Click "New SSH key."
6. Give it a descriptive "Title" (e.g., "My Work Laptop").
7. Paste the contents of your id_ed25519.pub file into the "Key" field.

The contents will look like this:

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIHf/w3b... your_email@example.com

For GitLab, it’s remarkably similar:

1. Go to GitLab’s website.
2. Click your profile picture in the upper-right corner.
3. Select "Settings."
4. In the left sidebar, click "SSH Keys."
5. Paste the contents of your id_ed25519.pub file into the "Key" field.
6. Give it a descriptive "Title" (e.g., "My Personal Machine").

The key difference, often missed, is that GitLab’s UI doesn’t have a separate "Title" field like GitHub’s. You just paste the key and give it a title directly. Both platforms store your public key and use it to verify your private key when you connect.

The problem this solves is obvious: typing your username and password (or a personal access token) every single time you git push or git pull is tedious and error-prone. SSH keys eliminate this by establishing a secure, encrypted channel based on asymmetric cryptography. Your local machine (holding the private key) proves its identity to the remote server (GitHub/GitLab) by performing a cryptographic challenge that only the corresponding public key can solve.

Internally, the process involves your local SSH client negotiating a connection with the remote Git server. When the server asks for authentication, your SSH client presents your public key. The server then sends a challenge message, which your client encrypts using your private key. The server receives this encrypted message, decrypts it with the public key you registered, and if it matches the original challenge, authentication succeeds.

The exact levers you control are the SSH key itself (its type and length, with Ed25519 being the modern, preferred choice for its speed and security over older RSA keys), and how you register that public key with each service. The private key must remain secret on your local machine.

If you ever find yourself being prompted for a password after setting up SSH keys, the most common culprit is that you haven’t added the SSH agent to your login session. This agent holds your decrypted private key in memory, so you only have to enter your passphrase once per session, rather than every time you interact with the Git remote. You can start it with eval $(ssh-agent -s) and add your key with ssh-add ~/.ssh/id_ed25519. Most modern terminal emulators and operating systems will handle this automatically, but if you’re on a minimal setup or a fresh install, you might need to kick it off manually.

Once your keys are set up and the agent is running, you’ll be able to clone repositories using the SSH URL (e.g., git@github.com:your-username/your-repo.git) instead of the HTTPS URL, and your git push and git pull commands will just work without any prompts.

The next hurdle you’ll likely face is managing multiple SSH keys for different services or different accounts on the same service, which requires configuring your SSH client’s config file.