SSH Keys for Git Hosts

This page shows how to set up an SSH key for each Git hosting service (forge) that GitComet works with. The steps are the same for GitComet and GitComet Pro: both use your local Git and OpenSSH setup for clone, fetch, pull, and push over SSH.

A GitComet Pro forge connection is separate from SSH. It uses a browser sign-in or a token to show pull requests and pipelines, and it does not change how Git authenticates. You still need an SSH key, or HTTPS credentials, to fetch and push.

For background on keypairs and how to view, back up, or delete keys, see SSH Keys. On Windows, run the commands below in Git Bash.

Overview

For each forge:

1. Create a key, usually one per forge and computer.
2. Add the public key (.pub) to your account on the forge.
3. Add a Host entry to ~/.ssh/config so SSH uses that key for that forge.
4. Test the connection with ssh -T.
5. Clone with the forge's SSH URL, or change an existing remote to it.

A separate key per forge lets you revoke one without touching the others. With several keys, an entry in ~/.ssh/config with IdentitiesOnly yes matters: without it, SSH offers every key it can find, and some servers disconnect after too many failed attempts.

Create a key

Ed25519 works with GitHub, GitLab, Bitbucket, Gitea, and Forgejo:

ssh-keygen -t ed25519 -C "you@example.com (gitlab)" -f ~/.ssh/id_gitlab

Azure DevOps accepts RSA keys only, on both Azure DevOps Services and Azure DevOps Server:

ssh-keygen -t rsa -b 4096 -C "you@example.com (azure devops)" -f ~/.ssh/id_azuredevops

-f chooses the file name, so the new key does not overwrite your default ~/.ssh/id_ed25519. -C is a comment that helps you recognize the key later in the forge's key list.

When ssh-keygen asks for a passphrase, set one. GitComet shows the passphrase prompt in the app when it needs the key. To avoid entering it every time, load the key into your SSH agent with ssh-add ~/.ssh/id_gitlab. To add or change a passphrase on an existing key, run ssh-keygen -p -f ~/.ssh/id_gitlab.

Print the public key to copy it:

cat ~/.ssh/id_gitlab.pub

Paste the entire single line, from the key type (ssh-ed25519 or ssh-rsa) to the comment. Never paste the private key, the file without .pub.

Point SSH at the key

Add one entry per forge to ~/.ssh/config. Create the file if it does not exist, and keep it readable only by you (chmod 600 ~/.ssh/config).

Host github.com
    HostName github.com
    User git
    IdentityFile ~/.ssh/id_github
    IdentitiesOnly yes

Host gitlab.com
    HostName gitlab.com
    User git
    IdentityFile ~/.ssh/id_gitlab
    IdentitiesOnly yes

Host ssh.dev.azure.com
    HostName ssh.dev.azure.com
    User git
    IdentityFile ~/.ssh/id_azuredevops
    IdentitiesOnly yes

Host bitbucket.org
    HostName bitbucket.org
    User git
    IdentityFile ~/.ssh/id_bitbucket
    IdentitiesOnly yes

Host gitea.com
    HostName gitea.com
    User git
    IdentityFile ~/.ssh/id_gitea
    IdentitiesOnly yes

Host codeberg.org
    HostName codeberg.org
    User git
    IdentityFile ~/.ssh/id_codeberg
    IdentitiesOnly yes

Keep only the forges you use. For a self-hosted server, use its host name in Host and HostName, and add a Port line if its SSH service does not listen on port 22.

The first time you connect, SSH asks you to confirm the server's host key fingerprint. Compare it with the fingerprint the forge publishes before you accept it: GitHub, GitLab.com, Azure DevOps, Bitbucket Cloud, and Codeberg. For a self-hosted server, ask its administrator.

GitHub

1. Create a key: ssh-keygen -t ed25519 -C "you@example.com (github)" -f ~/.ssh/id_github

2. On GitHub, open Settings → SSH and GPG keys (github.com/settings/keys) and choose New SSH key.

3. Keep Key type set to Authentication Key, paste the public key, and choose Add SSH key.

4. Test the connection:

   ssh -T git@github.com

   A working key replies Hi <username>! You've successfully authenticated, but GitHub does not provide shell access.

SSH URL format: git@github.com:owner/repository.git

If your organization uses SAML single sign-on, open Configure SSO next to the key on GitHub and authorize it for that organization. Until you do, Git operations on that organization's repositories fail even though ssh -T succeeds.

GitHub's official documentation:

• Generating a new SSH key and adding it to the ssh-agent
• Adding a new SSH key to your GitHub account
• Testing your SSH connection
• Authorizing an SSH key for use with single sign-on

GitLab

1. Create a key: ssh-keygen -t ed25519 -C "you@example.com (gitlab)" -f ~/.ssh/id_gitlab

2. On GitLab, select your avatar, then Preferences → SSH Keys (gitlab.com/-/user_settings/ssh_keys), and choose Add new key.

3. Paste the public key. Keep Usage type as Authentication & Signing, or choose Authentication. Set an expiration date if your policy requires one, then choose Add key.

4. Test the connection:

   ssh -T git@gitlab.com

   A working key replies Welcome to GitLab, @<username>!

SSH URL format: git@gitlab.com:group/project.git

For GitLab Self-Managed, use your server's host name instead of gitlab.com in the steps, the test, and ~/.ssh/config. When a key expires, GitLab stops accepting it, so add a new one before the date.

GitLab's official documentation: Use SSH keys to communicate with GitLab.

Azure DevOps

1. Create an RSA key: ssh-keygen -t rsa -b 4096 -C "you@example.com (azure devops)" -f ~/.ssh/id_azuredevops

2. In Azure DevOps, open User settings (the icon next to your avatar), then SSH public keys. You can also go to https://dev.azure.com/<organization>/_usersSettings/keys directly.

3. Choose + New Key, enter a name, paste the public key, and choose Add.

4. Test the connection:

   ssh -T git@ssh.dev.azure.com

   A working key replies remote: Shell access is not supported. That means the key was accepted. A rejected key reports Permission denied (publickey).

SSH URL format for Azure DevOps Services:

git@ssh.dev.azure.com:v3/<organization>/<project>/<repository>

For example, the repository at https://dev.azure.com/contoso/Website/_git/website clones with git@ssh.dev.azure.com:v3/contoso/Website/website. The repository's Clone button, under SSH, shows the exact URL.

Older *.visualstudio.com organizations use vs-ssh.visualstudio.com as the SSH host. Add a Host vs-ssh.visualstudio.com entry in ~/.ssh/config with the same key if your URLs use it.

On Azure DevOps Server, the SSH URL looks like ssh://devops.example.com:22/<collection>/<project>/_git/<repository>. Use the URL from the Clone button: the port and collection depend on your server.

An organization administrator can turn off SSH authentication. If SSH public keys is missing from your user settings, ask them, or use HTTPS with a personal access token instead.

Microsoft's official documentation: Use SSH key authentication.

If you also use GitComet Pro's Azure DevOps features, see Azure DevOps for the forge connection.

Bitbucket

1. Create a key: ssh-keygen -t ed25519 -C "you@example.com (bitbucket)" -f ~/.ssh/id_bitbucket

2. On Bitbucket Cloud, select the settings cog, then Personal Bitbucket settings → SSH keys (bitbucket.org/account/settings/ssh-keys), and choose Add key.

3. Enter a label, paste the public key, and choose Add key.

4. Test the connection:

   ssh -T git@bitbucket.org

   A working key replies that you are authenticated via SSH key and that shell access is disabled.

SSH URL format: git@bitbucket.org:workspace/repository.git

On Bitbucket Data Center, add the key under your avatar → Manage account → SSH keys. Its SSH service often listens on port 7999, so use the URL from the repository's Clone dialog, such as ssh://git@bitbucket.example.com:7999/project/repository.git.

Atlassian's official documentation:

• Bitbucket Cloud: set up personal SSH keys on Linux, macOS, or Windows
• Bitbucket Data Center: SSH user keys for personal use

Gitea and Forgejo

The steps are the same for Gitea, Forgejo, and the hosted services gitea.com and Codeberg, which runs Forgejo. Use the host name of your service in each step:

1. Create a key. For gitea.com:

   ssh-keygen -t ed25519 -C "you@example.com (gitea)" -f ~/.ssh/id_gitea

2. Add a Host entry for the service to ~/.ssh/config, as shown in Point SSH at the key.

3. Open your avatar, then Settings → SSH / GPG Keys (the SSH keys page in the table), and choose Add key under Manage SSH keys.

4. Enter a name, paste the public key, and choose Add key.

5. Optionally choose Verify next to the key and follow the instructions to prove you own it.

6. Test the connection:

   ssh -T git@gitea.com

   A working key replies with a greeting that names your account and the key, such as Hi there, <username>! You've successfully authenticated with the SSH key named <name>. followed by Gitea does not provide shell access. Forgejo servers say Forgejo instead of Gitea.

   The first connection asks you to confirm the server's host key. gitea.com offers an RSA host key with the fingerprint SHA256:Fo6Tm/SLyse8uglFB1JShqQWchU0kcPzSRueD1O9K0I.

SSH URL format: git@gitea.com:owner/repository.git, or git@codeberg.org:owner/repository.git on Codeberg.

Self-hosted servers may use a different SSH user or port. Use the SSH URL shown on the repository page, and match User and Port in ~/.ssh/config to it.

Gitea has no user guide for SSH keys. Codeberg's official documentation applies to Gitea and Forgejo servers too: Adding an SSH key to your account.

If you also use GitComet Pro's Gitea and Forgejo features, see Gitea and Forgejo for the forge connection.

Use the key in GitComet

Clone with the forge's SSH URL, or switch an existing HTTPS remote to SSH:

git remote set-url origin git@gitlab.com:group/project.git

GitComet then uses the key for fetch, pull, and push. If the key has a passphrase and is not loaded in your agent, GitComet asks for it. Automatic fetch does not open prompts, so load the key with ssh-add, or run Fetch all once to enter the passphrase.

Troubleshooting

Permission denied (publickey). The forge did not accept any key SSH offered. Check that you added the .pub file of the same key that IdentityFile names, and that the Host entry matches the host in the remote URL exactly. Run ssh -vT git@<host> to see which key files SSH tries.

Too many authentication failures. SSH offered several keys before the right one. Add IdentitiesOnly yes to the host's entry in ~/.ssh/config.

Works in the terminal but not in GitComet. GitComet must see the same SSH agent and ~/.ssh/config as your terminal. On Linux and macOS, start GitComet from a session where SSH_AUTH_SOCK is set. On Windows, make sure Git and GitComet use the same SSH client.

Host key verification failed. The server's host key is not in ~/.ssh/known_hosts or has changed. Run ssh -T git@<host> in a terminal, compare the fingerprint with the forge's published one, and accept it. If the host key has changed and the forge has not announced a change, do not accept it.