1

I ran into a very peculiar problem with Git. I have a repository on a Gitlab server and I usually work on it from my work computer in the office (which runs Ubuntu). On there, I have set up a private/public key and everything works just fine.

Now the weird part is, when I ssh into my work computer from home and execute a pull, or push, or any other Git command requiring connection to the Gitlab server, I get an error, saying that my public key is wrong.

$ git push
git@collaborating.tuhh.de: Permission denied (publickey).
fatal: Could not read from remote repository.

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

From my understanding, if I ssh into my work computer and execute a command in the shell, it should be exactly as if I am running that same command directly sitting in front of that computer, shouldn't it?

Does anyone have an idea, why this goes wrong? Any ideas welcome!

PeterO
  • 470
  • 3
  • 12
  • ***public key is wrong*** Isn't error message obvious? You should use the same public key/private key pair from your home computer to access the server. – kiner_shah Jan 15 '22 at 09:49
  • No, I think we are misunderstanding. I am not trying to push from my home computer. I am ssh-ing into my work computer and try to push from there, where I should have exactly the same key set-up, no matter if I am using it over ssh or directly, shouldn't I? – PeterO Jan 15 '22 at 09:51
  • Is your company's Gitlab server hosted in a private network for which you would require a VPN connection? – kiner_shah Jan 15 '22 at 09:53
  • Well, not a VPN, but to ssh into my work computer I need a ProxyJump, where I first ssh into a Login server within the company network and then from there I can ssh into my work computer. – PeterO Jan 15 '22 at 09:57
  • 1
    Maybe this helps: https://stackoverflow.com/a/36038548 – kiner_shah Jan 15 '22 at 09:59
  • Thanks, found out that it seems to not correctly read my ~/.ssh/config file when invoking git over ssh (although the log claims to do so). My keyfile has a non-standard name (not `id_rsa`), which is specified in the .ssh/config. Accordign to the ssh output, it only tries all the standard names for keyfiles (`id_dsa`, `id_rsa`,...). When I rename my keyfile to `id_rsa` it works. That would solve the issue, but still the question arises, why is it working differently over ssh than in presence? – PeterO Jan 15 '22 at 10:13
  • In order to use a different key file with SSH, there is I think a `-i` option. – kiner_shah Jan 15 '22 at 10:16
  • Yeah okay, that also works. Might be it has something to do with the way a bash shell is initialized, when ssh-ing into a computer versus when invoking it directly from the Ubuntu desktop? – PeterO Jan 15 '22 at 10:22
  • Maybe you can find out what SSH does when you use it directly from your work computer. – kiner_shah Jan 15 '22 at 10:23
  • 1
    Will do on Monday. Thanks for the help! – PeterO Jan 15 '22 at 10:24

1 Answers1

1

Ssh is, or can be, quite complicated and fancy. If you're using an ssh agent, remember that the agent will provide the keys, except when it doesn't.1 If you're not using an agent, the ssh configuration will always provide the keys.

Use ssh-add -l to view the keys the agent can see. Inspect your ~/.ssh/config file to see what keys you are telling ssh to send. Use ssh -v, or multiple -v options if desired (though one usually suffices), to observe which keys your ssh client is actually trying:

ssh -Tv git@github.com

for instance shows my ssh client offering my personal GitHub-specific RSA key to github.com.

On Git-for-Windows (not the case here but let's include it for other viewers), after making sure that ssh -Tv ... works, make sure that Git is using the Windows-native ssh. See Flimm's answer to How can I run git push/pull commands with SSH verbose mode? as kiner_shah mentioned in a comment.

1I realize this by itself is kind of unhelpful. The problem here is that there can be many reasons for "it doesn't". This is where the -v trick comes in handy. Note that IdentitiesOnly yes in the config means that only identities listed in the config will be used, although -i options will add on anyway.

torek
  • 448,244
  • 59
  • 642
  • 775