Introduction

Cloning a Git repository through SSH means Git authenticates with an SSH key instead of prompting for a password over HTTPS. This is the standard setup for developers who clone private repositories regularly because it is secure, repeatable, and works well with automation once configured correctly.

Use an SSH Remote URL

An SSH clone URL looks different from an HTTPS URL. For example:

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

That [email protected]:... form tells Git to use SSH and authenticate as the git user on the remote service. Different providers may show slightly different SSH URLs, but the pattern is the same: host, repository path, and SSH transport.

Generate an SSH Key If You Do Not Have One

If your machine does not already have a suitable SSH key, create one:

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

This command creates a public/private key pair. The private key stays on your machine. The public key is the part you upload to GitHub, GitLab, Bitbucket, or your internal Git server.

Load the Key into the SSH Agent

To avoid typing the key passphrase every time, add the private key to your local SSH agent:

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

Now your SSH client can present the key when Git connects.

Register the Public Key with the Git Host

Copy the public key and add it to your account on the Git hosting service:

cat ~/.ssh/id_ed25519.pub

Once that public key is registered, the server can trust connections signed by the matching private key on your machine.

Test SSH Before Cloning

Before blaming Git, test the SSH connection directly:

ssh -T [email protected]

For GitHub, a successful test usually prints a greeting that confirms authentication worked, even though the shell itself is not provided. Running this first makes troubleshooting much easier than jumping straight into git clone.

Then Clone Normally

After the key works, cloning is just a normal Git command:

git clone [email protected]:example-org/project.git
cd project
git remote -v

git remote -v is useful for confirming the repository really uses the SSH remote rather than HTTPS.

Understand the Most Common Failures

Most SSH clone problems fall into a small set of causes:

• The public key was never uploaded to the Git host.
• The SSH agent is not running or the key was not added.
• The wrong private key is being offered.
• The user does not have access to the repository.
• Network rules block SSH on port 22.

If port 22 is blocked, some providers support SSH over an alternate port or HTTPS as a fallback. That is a network issue, not a Git syntax issue.

Use ~/.ssh/config When You Have Multiple Keys

If you work with several Git accounts or separate corporate and personal keys, define host aliases in ~/.ssh/config so SSH uses the right key automatically. That avoids confusing permission errors caused by the wrong identity being offered first.

Common Pitfalls

• Trying to clone an SSH URL before the SSH key is registered with the remote service.
• Forgetting to start the SSH agent or add the private key.
• Using the wrong remote URL format.
• Assuming authentication succeeded when the actual problem is repository authorization.
• Blaming Git when the real issue is blocked SSH network access.

Summary

• SSH cloning uses an SSH key instead of password-based HTTPS auth.
• Generate a key pair, load the private key, and upload the public key.
• Test the SSH connection directly before troubleshooting git clone.
• Clone with the SSH remote URL provided by the Git host.
• If problems persist, check agent state, key selection, repository access, and network policy.