SSH vs HTTPS in Git: how to stop entering passwords and not lose your keys

Are you tired of entering passwords or tokens for every git pull and git push?
Do you copy your SSH key to every server and worry it might be stolen or “stuck” in logs?
In this article we’ll look at when to choose SSH, when HTTPS is better, how to securely set up access to GitHub / GitLab, and how not to turn CI/CD into a collection of tokens and passwords.

The choice between SSH and HTTPS is not a matter of preference, but a matter of security and automation convenience. Let’s figure out how to set up access so it doesn’t get in the way of work.

1. SSH: Keys and security

SSH (Secure Shell) is the standard for ongoing work. Instead of passwords, key pairs are used. You prove your identity by owning a private key that never leaves your machine.

How not to scatter keys (SSH Agent)

The main mistake is copying your private key to every server where you need to run git pull. That’s a security hole. Instead, use Agent Forwarding.

The gist: Your local computer acts as the “keeper” of the key. When a remote server wants to talk to GitHub, it forwards the request to your local agent.

1. Add the key to the agent locally

ssh-add ~/.ssh/id_ed25519

2. Allow forwarding in ~/.ssh/config

Instead of typing ssh -A every time, configure automation for the hosts you need:

Host my-server
    HostName 1.2.3.4
    User admin
    ForwardAgent yes

Now, after logging into my-server, you’ll be able to clone your private repositories there, but the key itself won’t be on the server.

2. Multiple accounts on one device

A common situation: work GitLab and personal GitHub. Using one key for everything is bad practice. To have Git automatically choose which key to use, use aliases in ~/.ssh/config.

2.1. Aliases in ~/.ssh/config

Example configuration:

# Work GitLab
Host gitlab.work
    HostName gitlab.company.com
    IdentityFile ~/.ssh/id_ed25519_work

# Personal GitHub
Host github.com
    HostName github.com
    IdentityFile ~/.ssh/id_ed25519_personal

How to use this:

• When cloning a work project use the host name from the config:

  git clone git@gitlab.work:department/project.git
  

• When working with personal GitHub the git remote addresses remain the standard git@github.com:user/repo.git.

3. When HTTPS is objectively better

Don’t write off HTTPS. Since GitHub moved to Personal Access Tokens (PAT), this protocol became indispensable in some cases.

3.1. Strict corporate networks

If system administrators have closed port 22 (SSH), HTTPS on the standard port 443 is your savior.

3.2. Docker and CI/CD

Inside Docker containers or ephemeral pipelines it’s easier to pass a token via an environment variable than to fuss with generating and registering SSH keys.

3.3. One-off tasks

If you need to quickly download code on someone else’s machine, it’s simpler to generate a temporary token in the browser than to leave keys behind.

3.4. Dangers of https://<TOKEN>@... and safe alternatives

Using a token directly in the URL:

git clone https://<TOKEN>@github.com/username/repo.git

is extremely unsafe: the token can end up in:

• shell history (~/.bash_history);
• CI/CD logs;
• screenshots and notes.

Better to do this:

• use git config with credential.helper:

  git config credential.helper store
  # then enter username/token at the first prompt
  

• or pass the token via environment variables in CI/CD (GitHub Actions, GitLab CI, etc.).

4. Comparing SSH and HTTPS

Conclusion:

• For your own machine and trusted servers — use SSH with an agent and ~/.ssh/config.
• For CI/CD, Docker builds, restricted networks, and one-off tasks — use HTTPS with tokens, but not tokens in URLs.

5. How to switch protocol in an existing project

If you cloned a project over HTTPS but want to switch to SSH (or vice versa), you don’t need to delete the folder and re-clone. Just change the remote repository URL.

Switch to SSH

git remote set-url origin git@github.com:user/repo.git

Switch to HTTPS

git remote set-url origin https://github.com/user/repo.git

After that all subsequent git pull / git push will use the new protocol.

Conclusion

For your own machine and trusted servers choose SSH with a configured agent and ~/.ssh/config — it’s secure, convenient, and scalable.
Reserve HTTPS for:

• CI/CD pipelines;
• Docker builds;
• restricted network conditions;
• one-off tasks.

A sensible combination of these approaches is mature DevOps practice.

Practical checklist: how to set up

1. Generate SSH keys:

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

2. Add the key to the SSH agent:

   ssh-add ~/.ssh/id_ed25519
   

3. Configure ~/.ssh/config for multiple accounts:

   Host gitlab.work
       HostName gitlab.company.com
       IdentityFile ~/.ssh/id_ed25519_work
   
   Host github.com
       HostName github.com
       IdentityFile ~/.ssh/id_ed25519_personal
   

4. Check access:

   ssh -T git@gitlab.work
   ssh -T git@github.com
   

5. In CI/CD use HTTPS with tokens via environment variables, not inserting them into URLs.