Permission denied (publickey) when using Nix's Git

Question

I installed Git via Nix (on Arch Linux).

[gorre@uplink ~]$ uname -a
Linux uplink 4.16.9-1-ARCH #1 SMP PREEMPT Thu May 17 02:10:09 UTC 2018 x86_64 GNU/Linux
[gorre@uplink ~]$ nix-env -q
erlang-20.3.2
git-2.16.3
go-1.10.1
google-drive-ocamlfuse-0.6.25
nix-2.0.2

I have the SSH config file saved in ~/.ssh/config:

[gorre@uplink ~]$ cat ~/.ssh/config 
# Bitbucket.org
Host bitbucket.org
#RSAAuthentication yes
IdentityFile ~/.ssh/bitbucket_id_rsa
IdentitiesOnly yes

I'm 100% sure the private/public key set is correct. I use it all the time in SmartGit, but when I try to use Git via the command-line, I'm getting this error:

[gorre@uplink erlang]$ git pull --rebase
sign_and_send_pubkey: signing failed: agent refused operation
git@bitbucket.org: Permission denied (publickey).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

Is there any way to tell Git (installed via Nix) to refer to my ~/.ssh/config file?

As a proof, this is what happens when I "instruct" the ssh-agent to temporarily use my public key (so you can be certain that I have the correct rights):

[gorre@uplink erlang]$ ssh-agent sh -c 'ssh-add ~/.ssh/bitbucket_id_rsa; git pull --rebase'
Enter passphrase for /home/gorre/.ssh/bitbucket_id_rsa: 
Identity added: /home/gorre/.ssh/bitbucket_id_rsa (/home/gorre/.ssh/bitbucket_id_rsa)
Already up to date.
Current branch master is up to date.

...after that, I'm free to fly for a while:

[gorre@uplink erlang_simple_cache]$ git pull --rebase
Already up to date.
Current branch master is up to date.

It's generally better to debug these as ssh failures rather than git failures. Diagnose them with `ssh -v -v git@bitbucket.org`. You should get the same error, and more diagnostics to work with. — Schwern, May 26 '18 at 21:43
"*sign_and_send_pubkey: signing failed: agent refused operation*" See https://askubuntu.com/questions/762541/ubuntu-16-04-ssh-sign-and-send-pubkey-signing-failed-agent-refused-operation#762558 `IdentityFile` only says which key to try, rather than trying all of them. That key still has to be made available. This is why it works after you `ssh-add`, that makes the key available to your ssh agent. `ssh-add` is the correct thing to do. — Schwern, May 26 '18 at 21:46
@Schwern, I knew about that, but my issue is that I have to add the private key (via that command) every time I restart the system. On the other hand, if I install Git with `pacman` or `Linuxbrew` I don't have those issues. It just doesn't know how to find the configuration data: `/home/gorre/.ssh/config`. — x80486, May 26 '18 at 22:02
It's not the ssh config, this is normal ssh behavior. Neither `pacman` nor `Linuxbrew` can unlock your ssh key for you; something needs to enter the passphrase. It's possible `pacman` and `Linuxbrew` are caching the passphrase from `ssh-add` in a keychain. Then they `ssh-add` for you when you login and unlock the keychain. This is what OS X does when you `ssh-add -K`. Again, this is not a Git issue, it's an ssh issue. You'll solve it by figuring out how to get your ssh-agent to cache your passphrases in a keychain. That's specific to your OS and better asked on SuperUser.com. — Schwern, May 26 '18 at 22:39
I believe this will help. https://wiki.archlinux.org/index.php/SSH_keys#Keychain — Schwern, May 26 '18 at 22:43
Well, well...I thought it was Git in the end. I installed that package and indeed, whenever I password-unlock it once it keeps it available "forever" for my user. Didn't know about that. You can place your last comment as an answer...I'll accept it. Thanks for the tip! — x80486, May 27 '18 at 00:23

R. Taukulis · Answer 1 · 2022-02-07T11:43:44.430

I encountered the same error message (on Debian) but with a different cause.

The problem was RSA SHA-1 deprecation in OpenSSH 8.8: https://www.openssh.com/txt/release-8.8 ("Potentially-incompatible changes").

Solved by generating and uploading a new ed25519 key.

Debugging the "Permission denied" error with ssh -v git@... was fruitless because git from /nix uses ssh from /nix, not the system ssh. GIT_TRACE=1 git ... output showed path to the ssh binary that is actually used.

score 1 · Accepted Answer · answered May 27 '18 at 00:29

It's generally better to debug these as ssh failures rather than git failures. Diagnose them with ssh -v -v git@bitbucket.org. You should get the same error, and more diagnostics to work with. But we already have the clue we need, sign_and_send_pubkey: signing failed: agent refused operation. Googling this we find it means the ssh-agent could not access that key.

IdentityFile only says which key to try, rather than trying all of them. That key still has to be made available. This is why it works after you ssh-add, that makes the key available to your ssh agent. Adding the key via ssh-add is the correct thing to do.

If it's annoying that you have to remember to add your key every time you login, then you can use a keychain to securely store your ssh key phase-phrases. Then next time you login your keychain will run ssh-add for you using your cached keychain. Keychains are different on every OS. Here's instructions for that on ArchLinux.

Permission denied (publickey) when using Nix's Git

2 Answers2