Error: Permission denied (publickey)

[akbarahs]

Hello Folks,

I followed this article to the letter : https://docs.github.com/en/authentication/troubleshooting-ssh/error-permission-denied-publickey?platform=linux but still get the publick key denied error message.

root@host1:~# ssh -T git@github.com
Hi akbarahs! You've successfully authenticated, but GitHub does not provide shell access.

root@host1:~# ssh-add -l
256 SHA256:SyBszNZ8Xvn7ST/ox1XkldLzBRN6gGxAZkTecGRzK2E <email-id>@gmail.com (ED25519)

root@host1:~# ssh-add -L
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAICKX+3Yi5V8ZARfHnOTEk8PJUaIiBhGwjEV3P44D0ZPy <email-id>@gmail.com

root@host1:~# git clone git@github.com:nonai/k8s-example-files.git
Cloning into 'k8s-example-files'...
git@github.com: Permission denied (publickey).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.
root@host1:~#

Any help is highly appreciated.

[knarrff]

Hi @akbarahs

So far, this all looks fine to me. In order to find out what is wrong, a debug log of the git-ssh connection might be useful (e.g., to see which key is actually used):

GIT_SSH_COMMAND="ssh -v" git clone git@github.com:nonai/k8s-example-files.git

[CapedBojji]

For some reason git clone doesnt use the ssh keys added it only attempts to read from the ssh directory even if the ssh key exist in ssh agent this is a huge problem for me rn.

[knarrff]

My understanding is:

1. ssh reads private keys from ~/.ssh/
2. If those keys are protected by a passphrase (most should be), it may ask an agent for the passphrase. It otherwise by default asks you directly.

You say ssh does not even try to read something in ~/.ssh? How did you configure ssh, especially: did you tell ssh which ssh key to use for github.com? If you didn't, it should try a few standard names. According to the documention (man ssh), those are: ~/.ssh/id_rsa, ~/.ssh/id_ecdsa, ~/.ssh/id_ecdsa_sk, ~/.ssh/id_ed25519, ~/.ssh/id_ed25519_sk and ~/.ssh/id_dsa. You can name yours differently, but then you have to tell ssh about it, e.g., by adding to .ssh/config:

Host github.com
    IdentityFile ~/.ssh/my_special_private_key

An excerpt from your log might tell us more, but you have not provided that, so it is a bit of guesswork.

[CapedBojji]

Yeah, but it should still read from the keys loaded by the ssh agent, every application does that already

[knarrff]

Without debug info all we can do is guess. What you/we are looking for in the output is something similar to this (which is my output):

debug1: get_agent_identities: bound agent to hostkey
debug1: get_agent_identities: agent returned 2 keys
debug1: Will attempt key: /home/user/.ssh/id_rsa RSA SHA256:xxx agent
debug1: Will attempt key: /home/user/.ssh/id_ed25519 ED25519 SHA256:xxx agent

We could guess that your agent does not offer the necessary key or that it does offer it but later something goes wrong, but all these would be are guesses.

[CapedBojji]

i found the reason. It is because the known_hosts file was not created

[CapedBojji]

What other troubleshooting steps have you taken to resolve this issue?
create the ssh_folder, add the known_host file then add the github to the know host file. look that up

[CapedBojji]

the reason is because the known_hosts file isnt created just create it and problem solved

[sonicsmooth]

Thanks, this solved my problem.
Specifically, my problem was that another application had set my HOME environment variable to another location that had nothing to do with my normal user profile. (F*k you Cadence!) So while ssh -T git@github.com worked fine at the DOS command prompt, git pull was still trying to use the known_hosts from the other HOME directory.

[sonicsmooth]

This is not the first time the HOME environment variable was incorrect. Specifically, Cadence is a big electronic schematic and PCB layout tool. When it installs on windows it sets the HOME variable to c:\SPB_Data instead of leaving it alone, or setting it to c:\Users<username>. So over the course of normal usage, eventually this c:\SPB_Data folder accumulates some stuff that really should belong in c:\users<username>, and it gets I think a partial mix of config data for ssh, git, and other random stuff.

When I use various linux-y tools on Windows, such as git or git bash, which despite their unix-y DNA, are actually running in a windows environment, they rely on the HOME variable to be consistent. When I tested ssh -T git@github.com, for some reason it used the normal c:\users<username>.ssh folder, but when I tried with git pull, it tried using the C:\SPB_Data folder, and with whatever incomplete configuration was present there, the git command failed.

Another time this particular c:\SPB_Data messed me up was when running emacs on windows. Emacs has kind of a priority list of where it finds its .emacs file, so sometimes it would write a new bare minimum file in c:\SPB_Data, when I was editing the real one in c:\user<username>. It took a while to figure out.

I have no end of curse words for this stupid Cadence tool. I need it for work and it's the industry standard. I reset my HOME variable yesterday to the usual value c:\users<username>, and briefly loaded up the schematic and layout tools, and they came up fine, so I'm not ever sure the tool requires the environment variable to be c:\SPB_Data.

When I use WSL, then ssh and git think they are really running on Linux, and there is no interference from Cadence. The HOME environment variable is set properly and everything works fine.