Why doesn't my SSH key work for connecting to github?

Question

Note: I'm not a newb, and I've done this a gazillion times, but for some reason today it decided not to work.

I keep getting the Permission denied (publickey). error message when trying to connect to github via SSH or when trying to clone a repo, even after remaking the ssh key and adding it to "SSH Keys" in my account.

This is what I tried to do ten times today without success:

1. make a key with ssh-keygen.
2. open ~/.ssh/id_rsa.pub with Gedit or Notepad++ and copy the contents.
3. Go to account settings on github.com
4. Go to SSH Keys
5. Click on the Add Key button.
6. give the key a title
7. paste the key into the key box.
8. Save the key (enter my github password to verify).

And now, when I try doing ssh github.com it just won't work.... What in the world? Am I just too tired right now or am I missing something?

Here's the output from ssh -vvv github.com

OpenSSH_5.9p1, OpenSSL 1.0.0f 4 Jan 2012
debug1: Reading configuration data /etc/ssh/ssh_config
debug2: ssh_connect: needpriv 0
debug1: Connecting to github.com [207.97.227.239] port 22.
debug1: Connection established.
debug3: Incorrect RSA1 identifier
debug3: Could not load "/home/trusktr/.ssh/id_rsa" as a RSA1 public key
debug1: identity file /home/trusktr/.ssh/id_rsa type 1
debug1: identity file /home/trusktr/.ssh/id_rsa-cert type -1
debug1: identity file /home/trusktr/.ssh/id_dsa type -1
debug1: identity file /home/trusktr/.ssh/id_dsa-cert type -1
debug1: identity file /home/trusktr/.ssh/id_ecdsa type -1
debug1: identity file /home/trusktr/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.1p1 Debian-5github2
debug1: match: OpenSSH_5.1p1 Debian-5github2 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.9
debug2: fd 3 setting O_NONBLOCK
debug3: load_hostkeys: loading entries for host "github.com" from file "/home/trusktr/.ssh/known_hosts"
debug3: load_hostkeys: found key type RSA in file /home/trusktr/.ssh/known_hosts:16
debug3: load_hostkeys: loaded 1 keys
debug3: order_hostkeyalgs: prefer hostkeyalgs: [email protected],[email protected],ssh-rsa
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: [email protected],[email protected],ssh-rsa,[email protected],[email protected],[email protected],[email protected],[email protected],ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,[email protected],hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,[email protected],hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,[email protected],zlib
debug2: kex_parse_kexinit: none,[email protected],zlib
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,[email protected],aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,[email protected],aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,[email protected],hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,[email protected],hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,[email protected]
debug2: kex_parse_kexinit: none,[email protected]
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: mac_setup: found hmac-md5
debug1: kex: server->client aes128-ctr hmac-md5 none
debug2: mac_setup: found hmac-md5
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug2: dh_gen_key: priv key bits set: 122/256
debug2: bits set: 510/1024
d    ebug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: RSA 16:27:ac:a5:76:28:2d:36:63:1b:56:4d:eb:df:a6:48
debug3: load_hostkeys: loading entries for host "github.com" from file "/home/trusktr/.ssh/known_hosts"
debug3: load_hostkeys: found key type RSA in file /home/trusktr/.ssh/known_hosts:16
debug3: load_hostkeys: loaded 1 keys
debug3: load_hostkeys: loading entries for host "207.97.227.239" from file "/home/trusktr/.ssh/known_hosts"
debug3: load_hostkeys: found key type RSA in file /home/trusktr/.ssh/known_hosts:16
debug3: load_hostkeys: loaded 1 keys
debug1: Host 'github.com' is known and matches the RSA host key.
debug1: Found key in /home/trusktr/.ssh/known_hosts:16
debug2: bits set: 497/1024
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /home/trusktr/.ssh/id_rsa (0x14cce60)
debug2: key: trusktr@rocketship (0x14ce2b0)
debug2: key: /home/trusktr/.ssh/id_dsa ((nil))
debug2: key: /home/trusktr/.ssh/id_ecdsa ((nil))
debug1: Authentications that can continue: publickey
debug3: start over, passed a different list publickey
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/trusktr/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey
debug1: Offering RSA public key: trusktr@rocketship
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey
debug1: Trying private key: /home/trusktr/.ssh/id_dsa
debug3: no such identity: /home/trusktr/.ssh/id_dsa
debug1: Trying private key: /home/trusktr/.ssh/id_ecdsa
debug3: no such identity: /home/trusktr/.ssh/id_ecdsa
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey).

Answer 1

The GitHub ssh setup mentions testing your GitHub connection with:

$ ssh -T [email protected]

That follow the ssh uri syntax (also illustrated in "this answer").

But you did:

ssh github.com

(without any user). In that case, ssh reverts to the SCP syntax, which relies on a ~/.ssh/config file, with a section "github.com", to list:

• the user
• the hostname
• (and optionally the public key location, but by default it will try ~/.ssh/id_rsa.pub)

To change it to a regular SSH URL, don't edit directly your .git/config file, as shown below.
Use the command git remote set-url:

git remote set-url origin [email protected]:username/repo.git

---

As noted by STEEL in the comments, should your private SSH key have a passphrase, you can add it to the ssh-agent with:

• on Mac: ssh-add -K or (2023) ssh-add --apple-use-keychain
• on Linux/Windows: ssh-add

Answer 2

I had a similar problem, github did not use my SSH key. I always had to enter my username and password.

I've been looking at .git/config, under [remote "origin"] there was:

    url = http://github.com/path/to/repository

or

    url = https://github.com/path/to/repository

I changed the line into

    url = ssh://[email protected]/path/to/repository

and then it worked.

Answer 3

After creating a config file (~/.ssh/config) it worked. This is what I had to put in it:

Host github.com
User git
Port 22
Hostname github.com
IdentityFile ~/.ssh/id_rsa
TCPKeepAlive yes
IdentitiesOnly yes

Thanks to @VonC for leading me to there in the comments.

I don't get why I never needed this before though.

Answer 4

If it works for other repositories, but not one in particular, then you are probably using the wrong remote url(i.e. https instead of [email protected])

1. First, double check that your git ssh connection is working:

    ssh -T [email protected]
   

2. If it works, check your remote:

    git remote -v
   

   it will display something like this:

    origin  https://github.com/ownername/repo(fetch)
    origin  https://github.com/ownername/repo(push)
   

   where ownername is either your username or your organization name (the "owner" of the repository).

3. If the remotes indicate https at the beginning, then you need to change this url with:

    git remote set-url origin [email protected]:ownername/repo.git
   

Go here for more details.

Answer 5

I was getting some weird line ending issue in Windows when copying the clone address from github.

Note the extra character before git. It was NOT appearing in my console. It was invisible.

git clone [email protected]:user/repo.git ./docker
Cloning into './docker'...
Warning: Permanently added the RSA host key for IP address '140.82.XXX.X' to the list of known hosts.
\302\[email protected]: Permission denied (publickey).
fatal: Could not read from remote repository.

It took me a while to notice the \302\226 before git in the response. Once I saw that, I backspaced before git@ and made sure there was just a space there and it worked.

Answer 6

This is what worked for me:

git remote set-url origin [email protected]:<YOUR-USERNAME>/<YOUR-REPOSITORY>.git

Change the items in the <> and run the command, and then try a git push.

Github.com's page on managing remote repositories helped me.

Answer 7

GitHub recently underwent an audit of ALL keys. Go to the key section of your account to re-approve it.

Answer 8

For ssh you need to change the url. Open up the git config file and change the url to

url = [email protected]:username/repository.git

Answer 9

Another possible cause is permissions.

This weekend I have had the same problem with a new laptop and been unable to push to github even though my ssh key has been in Github for years.

The permissions on your ~/.ssh/ directory should be 700 and your id_rsa and id_rsa.pub should be 600

When I copied my keys to the new laptop my permissions were too permissive.

More info: https://help.ubuntu.com/community/SSH/OpenSSH/Keys

Answer 10

Worked for me after below:

git remote set-url origin [email protected]:username/repo.git

ssh -T [email protected]

Answer 11

This is a critical security configuration, so please do this with care.

GitHub has just changed their SSH server keys and a manual update is required at client side, the steps are at:

https://github.blog/2023-03-23-we-updated-our-rsa-ssh-host-key/

And the official SSH finger prints to carefully check are at https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/githubs-ssh-key-fingerprints

IMPORTANT: To prevent possible attacks, ensure the new finger prints are the official ones, if unsure, just run ssh-keygen -R github.com and try again

Answer 12

If the issue is due to multiple ssh keys used/listed in ~/.ssh folder then it can be fixed by specifying the correct ssh keys with any git command using git environment variable GIT_SSH_COMMAND. Run this in your terminal under your git repository:

GIT_SSH_COMMAND='ssh -i ~/.ssh/your_private_key' git submodule update --init

Replace ~/.ssh/your_private_key with the path of ssh private key you wanna use. And you can change the subsequent git command (in the example is git submodule update --init) to others like git pull, git fetch, etc.

Credit: https://stackoverflow.com/a/43953433/4170265

Answer 13

I had a similar issue when moving from Windows 7 to Windows 10 using Git for Windows.

I had my SSH keys for a Gitlab of our company running on my old computer and using this ssh command in the Windows cmd or the Git Bash worked fine (with git.my_server.com replaced by the Git server domain) - so my Windows was able to use the key, but Git for Windows was not:

ssh -T [email protected]_server.com

(which displayed: "Welcome to GitLab, @my_username!). However, when trying to clone, push or pull with git, I got the "Permission denied (publickey)" error message.

I initially couldn't find the location/environment of the SSH keys that Git uses, so I tried to copy/paste the ssh keys into this environment by using the Git Bash:

1. Open the Git Bash from the Windows Start Menu (not from a directory). Enter

   pwd

   I later found out that this returns the location of your ssh keys. In my case this returned '/u/', which was a network drive mounted as "U:\" in my Windows account.

2. Type cd .ssh, then dir. This may list your currently existing id files, like id_rsa and id_rsa.pub. I deleted these files since I didn't need them anymore (you might want to skip this if you successfully used other SSH keys on your installation, e.g. for other Git Servers):

   rm id_rsa

   rm id_rsa.pub

3. Create a new id_rsa file (if you have an existing id_rsa file, you can also use another name, like id_rsa_gitlab_my_username or something like that. Add .pub to this name for the public key):

   vi id_rsa and press the 'i' on your keyboard to switch to text insertion mode. Now copy the content of your private key file (I had mine in C:\Users\my_windows_username.ssh\id_rsa and used Notepad++ to copy the complete content, Windows notepad works fine as well). Press Escape on your keyboard to exit text insertion mode, then enter ':' and 'x', then Enter to save the file. Repeat this for the public key file.

4. If you use multiple SSH keys or used another name for the id_rsa file, you should also create a 'config' file or copy the content of your existing configuration file:

   vi config

   (Again, press 'i', insert text, press ':', 'x', then Enter.) My file looks like this (use your server, user and SSH file name):

   #SCC Gitlab
       Host git.my_server.com
       HostName git.my_server.com
       User git
       IdentityFile ~/.ssh/id_rsa
   

Now my Git for Windows was able to push, pull and clone without problems again.

Answer 14

First, try this (changing your email address as needed)

 ssh-keygen -t rsa -b 4096 -C "[email protected]"

If you're creating using Cygwin, there might be confusion about the home directory, which is what happened for me, as I was referring to (copying to GitHub) an old/incorrect key from a different directory. So in case this happens for you, after creating the key, do:

$ explorer .

Which will pop up a windows explorer window, showing your full/absolute path. That's when I saw the ~ directory was actually my Cygwin directory

C:\Program Files\cygwin64\home\{your_username}\.ssh

I was then able to copy my private SSH key and paste in GitHub, and cloning, etc.. then worked.

Answer 15

I had a similar problem on Gnome. Configuration was alright but keys weren't added to ssh-agent. A reboot did the trick. Gnome Keyring uses it's own ssh-agent.

Answer 16

In my case it was because I have 2 users, both had an SSH key. The first one that was authenticated wasn't the one I needed. So I deleted the SSH key from it.

This command helped me understand which user is being used because of it's output:

ssh -T [email protected]

Answer 17

you need to edit remote URL settings, just follow this step:

1. Open Terminal.

2. Change the current working directory to your local project.

3. List your existing remotes in order to get the name of the remote you want to change.

$ git remote -v

4. Change your remote's URL from HTTPS to SSH with the git remote set-url command. change USERNAME and REPOSITORY as yours.

$ git remote set-url origin [email protected]:USERNAME/REPOSITORY.git

5. Verify that the remote URL has changed.

$ git remote -v

Verify new remote URL

now will shows:

origin [email protected]:USERNAME/REPOSITORY.git (fetch)
origin [email protected]:USERNAME/REPOSITORY.git (push)

After this you will never found Permission denied (publickey) and your push will run okay.

Answer 18

In .git/config I changed

[remote "origin"]
        url = https://path/to/the/repo.git

to

[remote "origin"]
        url = [email protected]:path/to/the/repo.git

It started working without any problem. In addition, if you have previously cloned your project before setting up your SSH key, recloning will solve the problem. Ensure that your local repository is up to date with your remote repository.

Answer 19

In my case, it was related to DNS mapping (bitbuket was not pointing to the correct IP) I fixed it with doing a simple trick (i overwritten the IP address to point when looking for bitbucket.org)

open and edit /etc/hosts in ubuntu (in case of any other OS please look how can you can do the same)

sudo vim /etc/hosts

and add the following line (in the case of GitHub or any other website look for the IP and do the mapping accordingly)

18.205.93.2 bitbucket.org

and then it'll resolve the issue

Answer 20

In my case, I was using sudo to clone the repository like in /var/www/html/ dir:

sudo git clone [email protected]:<user>/repos.git

I solved it by: adjusting the permissions of directory /var/www/html sudo chmod a+w -R /var/www/html (use your own permission) Then I could clone without sudo.

Answer 21

If you are using an AWS EC2 instance, make sure to have a public IPv4 address. I only had an IPv6 address. GitHub still does not support SSH for IPv6 addresses for clone operations. You can follow the discussion at this link:

https://github.com/orgs/community/discussions/10539