Skip to content

Permission denied (publickey) on cmd but not on git-bash #848

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
1 task done
tlescoat opened this issue Aug 10, 2016 · 12 comments
Closed
1 task done

Permission denied (publickey) on cmd but not on git-bash #848

tlescoat opened this issue Aug 10, 2016 · 12 comments

Comments

@tlescoat
Copy link

tlescoat commented Aug 10, 2016

  • I was not able to find an open
    or closed issue
    matching what I'm seeing.

Setup

  • Version of Git for Windows : 2.9.2, 32-bit and 64-bit (probably irrelevant to the question)
  • Version of Windows : Windows 7 64-bit (probably irrelevant also)
  • Installation options :
    • use git from cmd (but not other tools)
    • after installation only C:\Program Files\Git\cmd is added to PATH
    • content of ...\Git\bin and ...\Git\cmd :
        bin/
            bash.exe
            git.exe
            sh.exe
        cmd/
            git.exe
            git-gui.exe
            gitk.exe
            start-ssh-agent.cmd
            start-ssh-pageant.cmd

Details

Git from git-bash does work perfectly. However git from CMD is near unusable since it cannot use ssh, so no remote operations like push, pull, fetch... Example:

From Git bash:

bash> git ls-remote origin refs/heads/master*
d4aca6552c07067586da8305d7632d2698fd15f0        refs/heads/master

From CMD:

cmd> git ls-remote origin refs/heads/master*
Permission denied (publickey).
fatal: Could not read from remote repository.

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

Note that these commands were run in the exact same repository.

I expected it to work the same regardless of the shell, as was advertised in the installer. I think it is a bug, but if you consider it a feature, then please clarify it in the installer (by adding a sentence for it, like "Note that git from CMD won't be able to use ssh.")

@dscho
Copy link
Member

dscho commented Aug 10, 2016

Permission denied (publickey).

(BTW the title of this ticket ("SSH not available") is really misleading. You would not get that message if SSH was really not available.)

That looks as if your $HOME/.ssh/config is somehow not found.

You should be able to find out more by adding an alias that calls ssh -v -v -v -v <user>@<host> and running it from both Bash and CMD. Something like

[alias]
    ssh-test = !ssh -v -v -v -v [email protected]

in the .git/config (obviously requiring edits, please be careful not to copy/paste blindly) should do the trick.

@tlescoat
Copy link
Author

tlescoat commented Aug 10, 2016

Sorry for the title, if you see something better I will be happy to edit it !

I just tried what you did and both on cmd and git bash the ssh config file was read. However, with git-bash the passphrase was not needed (I have a running ssh agent), while in CMD I had to enter my passphrase.
So if git does indeed find ssh, why it does not find the ssh-agent (or just asks for the passphrase) ?

I do not have a %HOME% environment variable (in CMD), however when I set it to %USERPROFILE% it does not change the observed behavior...

@whoisj
Copy link

whoisj commented Aug 10, 2016

Sorry for the title, if you see something better I will be happy to edit it !

How about "ls-remote returns: 'fatal: Could not read from remote repository when using SSH'"

I do not have a %HOME% environment variable (in CMD), however when I set it to %USERPROFILE% it does not change the observed behavior...

The GitWrapper already does something similar. My guess it is some interaction between your environment and how the Git for Windows ecosystem operates. Git-Bash gets to do more setup and therefore has more control over the environment than Cmd does.

Is you Git installation on the %PATH% from CMD? What does your %PATH% look like?

Do you SSH_ASKPASS or GIT_ASKPASS set?

@tlescoat tlescoat changed the title SSH not available in windows cmd Permission denied (publickey) on cmd but not on git-bash Aug 10, 2016
@tlescoat
Copy link
Author

tlescoat commented Aug 10, 2016

How about "ls-remote returns: 'fatal: Could not read from remote repository when using SSH'"

The problem is more general than just ls-remote, actually all network-related commands fail. I tried a more explicit title.

Is you Git installation on the %PATH% from CMD? What does your %PATH% look like?

Yes (as said in the "setup" part of the OP). The last component of PATH is C:\Program Files\Git\cmd and no other components are related to git.

Do you SSH_ASKPASS or GIT_ASKPASS set?

For git-bash, SSH_ASKPASS = /mingw64/libexec/git-core/git-gui--askpass and GIT_ASKPASS is not set.
For cmd, both SSH_ASKPASS and GIT_ASKPASS are not set. I don't know what to put in SSH_ASKPASS since for git-bash it seems to point to a bash script.

@tlescoat
Copy link
Author

I have some other info. I added GIT_TRACE=1 and GIT_SSH_COMMAND=ssh -vvv environment variables in CMD and tried a git fetch. Here is the beginning of the log

12:14:37.287757 git.c:350               trace: built-in: git 'fetch'
12:14:37.292258 run-command.c:336       trace: run_command: 'ssh -vvv' '[email protected]' 'git-upload-pack '\''myproject.git'\'''
OpenSSH_7.1p2, OpenSSL 1.0.2h  3 May 2016
debug1: Reading configuration data /c/Users/Thibault/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug2: ssh_connect: needpriv 0
debug1: Connecting to mydomain.com [xx.xx.xx.125] port 22.
debug1: Connection established.
debug1: key_load_public: No such file or directory
debug1: identity file /c/Users/Thibault/.ssh/id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /c/Users/Thibault/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /c/Users/Thibault/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /c/Users/Thibault/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /c/Users/Thibault/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /c/Users/Thibault/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /c/Users/Thibault/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /c/Users/Thibault/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.1
debug1: Remote protocol version 2.0, remote software version SSHD-CORE-0.13.0
debug1: no match: SSHD-CORE-0.13.0
debug2: fd 3 setting O_NONBLOCK

ssh finds the config file, but for some reason doesn't use it. BTW my config is the following:

Host github.com
    User git
    HostName github.com
    IdentityFile ~/.ssh/keys/github
    RequestTTY no

Host bitbucket.org
    User git
    HostName bitbucket.org
    IdentityFile ~/.ssh/keys/bitbucket
    RequestTTY no

I notice ssh is also trying to read /etc/ssh/ssh_config. Maybe this has something to do with the problem ?

@dscho
Copy link
Member

dscho commented Aug 12, 2016

Please note that you have to have the environment variables set up correctly for SSH agent to be accessible. In Git Bash, it is probably your ~/.bash_profile that sets these up. In Git CMD, you have to use start-ssh-agent.cmd or imitate it yourself.

@dscho
Copy link
Member

dscho commented Aug 25, 2016

@tlescoat did you manage to figure out where you set up the SSH agent connection in your Bash profile?

@dscho
Copy link
Member

dscho commented Sep 8, 2016

I guess it is some Bash profile issue. Would be nice to know for sure, though.

@dscho dscho closed this as completed Sep 8, 2016
@drewcrawford
Copy link

I ran into a similar issue (works under git bash, not under windows cmd).

With GIT_TRACE=1 and GIT_SSH_COMMAND=ssh -vvv I was able to trace it to an lfs subcommand

 trace: exec: git-lfs pre-push origin [email protected]:drewcrawford/example.git

This then spawns another ssh task, which fails.

21:36:29.984311 trace git-lfs: run_command: sh -c ssh -vvv -- [email protected] 'git-lfs-authenticate drewcrawford/example.git upload'
21:36:30.407450 trace git-lfs: ssh: [email protected] failed, error: exit status 255, message: OpenSSH_8.1p1, OpenSSL 1.1.1d  10 Sep 2019

This fails, because

debug1: Server accepts key: /c/Users/drew/.ssh/id_rsa RSA SHA256:XXXXX
debug3: sign_and_send_pubkey: RSA SHA256:XXXX
debug3: sign_and_send_pubkey: signing using rsa-sha2-512
debug1: read_passphrase: can't open /dev/tty: No such device or address
debug2: no passphrase given, try next key

From what I can tell, "cmd ssh" and "sh ssh" are in fact two different executables, with slightly different versions. For whatever reason, lfs insists on talking to the latter, and the latter does not work under windows cmd, apparently due to some tty issue or otherwise can't prompt for a password interactively.

Unclear to me why it can't talk to ssh-agent from cmd in this case. That's as far as I got.

@dscho
Copy link
Member

dscho commented Jul 26, 2021

@drewcrawford in general, it is a good idea to open a new ticket instead of adding a comment to a ticket that has been resolved almost five years ago.

From what I can tell, "cmd ssh" and "sh ssh" are in fact two different executables, with slightly different versions. For whatever reason, lfs insists on talking to the latter,

Most likely git-lfs.exe should be called via the non-dashed form, then, i.e. git lfs [...] instead of git-lfs [...]. That will set up the PATH for Git LFS correctly so that Git for Windows' internal copy of OpenSSH is used.

Unclear to me why it can't talk to ssh-agent from cmd in this case.

There are most likely two very different OpenSSH builds at play: the internal copy shipped with Git for Windows, which is based on the MSYS2 runtime, a POSIX emulation layer. Only MSYS programs linking to the same MSYS2 runtime have access to emulated things (such as /dev/tty or the Unix sockets on which ssh-agent listens).

The other OpenSSH version is the native one built by the PowerShell-w32 team, and it does not even seem to require a POSIX emulation layer. And it certainly does not have any way to access the other OpenSSH's ssh-agent's socket.

@drewcrawford
Copy link

After debugging this further, looks related to #2944

Namely, system32\OpenSSH\git.exe works, communicates with win32 ssh-agent, and is the executable seemingly preferred by top-level git in the command prompt. However some other nestings, such as when git shells out to git-lfs, end up in C:\Program Files\Git\usr\bin\ssh.exe. This means that in a single command like git push, there can be multiple ssh versions getting launched at various depths.

usr\bin\ssh usually works, but in some nestings I don't totally understand it isn't able to prompt for a password. The tty error is one of several strategies it tries, usually one of which actually works. But it appears in certain nestings where the command prompt is toplevel, and some sh invocations at lower levels, it cannot prompt and the key is skipped.

Forcing system32 ssh everywhere seems to be an effective solution

set GIT_SSH_COMMAND='c:\windows\system32\openssh\ssh.exe'

@dscho
Copy link
Member

dscho commented Jul 29, 2021

system32\OpenSSH\git.exe works, communicates with win32 ssh-agent, and is the executable seemingly preferred by top-level git in the command prompt. However some other nestings, such as when git shells out to git-lfs, end up in C:\Program Files\Git\usr\bin\ssh.exe

I would be surprised if that was the case. I think it is the other way round. git.exe prefixes the PATH so that Git for Windows' copy of OpenSSH is found first. But git-lfs.exe does not have that behavior, it would not find that copy but find system32's copy instead.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants