Think of SSH keys as your gatekeeper to GitLab minus the small talk and awkward passwords. This short guide walks you through generating a modern key pair registering the public key with GitLab and using ssh agent tricks to avoid typing your way into madness. It is a practical DevOps tutorial for people who care about security but also have deadlines.

Generate an SSH key pair

Use a modern key type for better security and less drama. Ed25519 is a good default because it is secure and tiny. If you prefer RSA for compatibility that works too but pick at least 3072 bits.

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

Press Enter to accept the default path unless you want a custom file name. Add a passphrase if you want an extra lock on the private key. Leave it blank when you need unattended automation for pipelines.

Add the public key to your GitLab profile

Copy the public key and paste it into the GitLab web console under Profile Settings then SSH Keys. On Unix like systems do this to view the key.

cat ~/.ssh/id_ed25519.pub

Give the key a clear title that future you can scan without a panic attack. Include host or purpose like work laptop or ci runner.

Start the SSH agent and add your private key

Let the agent hold your private key so you are not typing your passphrase a dozen times. On a Unix like shell run these commands.

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

On Windows use the OpenSSH agent service or a GUI key manager such as the one bundled with Git for Windows. The goal is the same. Make the agent cache the key so git push and git pull stop sounding like a broken elevator.

Optional SSH config for juggling accounts

If you have personal and work accounts or multiple GitLab instances a simple SSH config picks the right key per host. Create or edit the file at ~/.ssh/config and set permissions to user only.

Host gitlab.com
  User git
  IdentityFile ~/.ssh/id_ed25519

Host gitlab-work
  HostName gitlab.com
  User git
  IdentityFile ~/.ssh/id_ed25519_work

Then use git remote set-url or add a remote that points to the correct Host entry. This prevents accidental pushes from the wrong account when you are juggling identities like a tired circus performer.

Test the connection and use with repositories

Verify GitLab recognizes your key with a test authentication. You will get a friendly or at least informative message if things work.

ssh -T git@gitlab.com

A successful auth will show a welcome message. After that add SSH remotes or update existing ones and push or pull as usual. Example remote form is git@gitlab.com:username/repo.git but the ssh test uses the git at host syntax.

Troubleshooting tips

• If SSH says permission denied check that the public key was copied correctly and that you added the right one to your GitLab account.
• If the wrong key is used confirm your ~/.ssh/config points to the right IdentityFile and that ssh agent is not offering the wrong key first.
• If you see host key warnings verify the known hosts entry and confirm you are talking to the real gitlab host and not that weird network appliance.
• If SSH agent refuses to add the key check file permissions on the private key. It should be readable only by your user.

Recap and quick security pointers

• Generate a modern key with ssh-keygen and prefer ed25519 when possible.
• Add the public key to GitLab under Profile Settings then SSH Keys with a clear title.
• Use ssh agent and ssh-add to cache keys for smoother git operations.
• Use an SSH config file to handle multiple accounts and avoid accidental pushes.
• Keep private keys private and consider passphrases for better security.

There you go. Secure GitLab SSH access without the drama and with enough sarcasm to keep you awake while you finish the merge request.