Introduction

Git does not independently "choose" SSH or HTTPS when you clone a repository. It uses whatever remote URL you provide, so the practical way to make new repositories use SSH is to rewrite matching HTTPS URLs into SSH URLs and to make sure your SSH keys are configured correctly.

Rewrite HTTPS URLs to SSH with insteadOf

The most effective global setting is url.<base>.insteadOf. It tells Git to replace one URL prefix with another before it connects.

For GitHub:

git config --global url."[email protected]:".insteadOf "https://github.com/"

For GitLab:

git config --global url."[email protected]:".insteadOf "https://gitlab.com/"

After that, this command:

git clone https://github.com/example/project.git

is treated by Git as if you had typed:

git clone [email protected]:example/project.git

You can inspect the active configuration with:

git config --global --get-regexp '^url\\..*\\.insteadOf$'

This approach is useful because it works across normal git clone, submodule updates, and tools that hand Git an HTTPS URL under the hood.

Make Sure SSH Authentication Actually Works

URL rewriting only solves the protocol selection. You still need a usable SSH key and host configuration.

Generate a key if you do not already have one:

ssh-keygen -t ed25519 -C "[email protected]"

Load it into the agent:

ssh-add ~/.ssh/id_ed25519

Then add the public key to your Git hosting account and test the connection:

ssh -T [email protected]

If you use multiple keys, an SSH config file keeps the mapping explicit:

1Host github.com
2    HostName github.com
3    User git
4    IdentityFile ~/.ssh/id_ed25519
5    IdentitiesOnly yes

That prevents Git from trying the wrong key when several identities are loaded.

Update Existing Repositories Separately

The rewrite rule affects future remote URL resolution, but existing clones keep their current origin URL until you change it.

git remote -v
git remote set-url origin [email protected]:example/project.git
git remote -v

If you want to see the exact remote URL a repository uses, inspect .git/config or run git remote get-url origin.

One subtle point matters here: browser links and hosting service copy buttons may still show HTTPS by default. That does not override Git configuration. It just means the displayed text is different from the rewritten URL Git will eventually use.

Per-Host and Per-Organization Variants

You can define more specific rewrite rules when needed. For example, if only one organization should use SSH rewriting:

git config --global url."[email protected]:my-org/".insteadOf "https://github.com/my-org/"

Git matches the longest applicable prefix, so specific rules can live alongside broader ones. That is useful in mixed environments where public repositories use HTTPS but internal repositories require SSH.

It is also worth knowing that Git accepts two common SSH URL styles:

[email protected]:owner/repo.git
ssh://[email protected]/owner/repo.git

Both work, but the insteadOf replacement must match the style you want Git to produce. The SCP-like form is shorter and is the one most developers use for GitHub and GitLab examples.

Common Pitfalls

• Expecting Git to change protocols without configuration. Git uses the URL it receives unless you add rewrite rules.
• Forgetting SSH key setup. A rewritten SSH URL fails immediately if the key is missing or not registered with the host.
• Using the wrong replacement format. For GitHub-style SCP syntax, the replacement should look like [email protected]:.
• Assuming existing clones will update automatically. Remotes already stored in .git/config must be changed explicitly.

Summary

• Git defaults to the remote URL you provide, not to a built-in protocol preference.
• Use url.<base>.insteadOf to rewrite HTTPS URLs into SSH globally.
• Configure and test your SSH key so the rewritten URLs actually authenticate.
• Update existing repository remotes with git remote set-url.
• Use host-specific or organization-specific rewrite rules when you need finer control.