[英]Why git clone works only in Powershell running as administrator?
I configure ssh key
for my Gitlab
account and want to git clone
my repo, but cloning works only in Powershell
running as administrator.我为我的Gitlab
帐户配置了ssh key
并希望git clone
我的 repo,但克隆仅在以管理员身份运行的Powershell
中有效。
The command below works the same in both cases (with admin rights and without):以下命令在两种情况下的工作方式相同(有管理员权限和没有管理员权限):
ssh -T git@my.gitlab.host.com
The output is: Welcome to GitLab, @username!
输出是: Welcome to GitLab, @username!
How I can make to work git clone
without running Powershell
as administrator?如何在不以管理员身份运行Powershell
的情况下使git clone
工作?
Update 1 :更新 1 :
whoami
output also the same for both cases (with admin rights and without)两种情况下whoami
的输出也相同(有管理员权限和没有管理员权限)
Update 2 :更新 2 :
git clone
command error: git clone
命令错误:
git@my.gitlab.host.com: Permission denied (publickey). git@my.gitlab.host.com:权限被拒绝(公钥)。 fatal: Could not read from remote repository.致命:无法从远程存储库中读取。
Please make sure you have the correct access rights and the repository exists.请确保您具有正确的访问权限并且存储库存在。
Update 3 :更新 3 :
git push
command fails with the same error. git push
命令失败并出现同样的错误。 Problem with access to private ssh key
located in ~/.ssh/id_rsa
?访问位于~/.ssh/id_rsa
中的私有ssh key
有问题吗?
Update 4 :更新 4 :
I set the default ssh
command for git
( ssh -Tv
) as VonC suggested, but with this command:我按照VonC的建议为git
( ssh -Tv
) 设置了默认ssh
命令,但是使用以下命令:
git config --global core.sshCommand "ssh -Tv"
(setting the GIT_SSH_COMMAND
was not worked for me) git config --global core.sshCommand "ssh -Tv"
(设置GIT_SSH_COMMAND
对我不起作用)
First 19 lines output for git pull
command (no admin): git pull
命令的前 19 行输出(无管理员):
OpenSSH_8.8p1, OpenSSL 1.1.1m 14 Dec 2021
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Connecting to my.gitlab.host.com [my.gitlab.host.ip] port 22.
debug1: Connection established.
debug1: identity file /t/.ssh/id_rsa type -1
debug1: identity file /t/.ssh/id_rsa-cert type -1
debug1: identity file /t/.ssh/id_dsa type -1
debug1: identity file /t/.ssh/id_dsa-cert type -1
debug1: identity file /t/.ssh/id_ecdsa type -1
debug1: identity file /t/.ssh/id_ecdsa-cert type -1
debug1: identity file /t/.ssh/id_ecdsa_sk type -1
debug1: identity file /t/.ssh/id_ecdsa_sk-cert type -1
debug1: identity file /t/.ssh/id_ed25519 type -1
debug1: identity file /t/.ssh/id_ed25519-cert type -1
debug1: identity file /t/.ssh/id_ed25519_sk type -1
debug1: identity file /t/.ssh/id_ed25519_sk-cert type -1
debug1: identity file /t/.ssh/id_xmss type -1
debug1: identity file /t/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.8
First 9 lines output for git pull
command (admin): git pull
命令(管理员)的前 9 行输出:
OpenSSH_8.8p1, OpenSSL 1.1.1m 14 Dec 2021
debug1: Reading configuration data /c/Users/my_user/.ssh/config
debug1: /c/Users/my_user/.ssh/config line 1: Applying options for my.gitlab.host.com
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Connecting to my.gitlab.host.com [my.gitlab.host.ip] port 22.
debug1: Connection established.
debug1: identity file C:/Users/my_user/.ssh/id_rsa type 0
debug1: identity file C:/Users/my_user/.ssh/id_rsa-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.8
So it looks like in no-admin mode it even do not try to find keys/configs in right location.所以看起来在无管理员模式下它甚至不会尝试在正确的位置找到密钥/配置。 Any ideas of this behavior?对这种行为有任何想法吗?
In both instances (admin or no admin), set first:在这两种情况下(管理员或无管理员),首先设置:
set "GIT_SSH_COMMAND=ssh -Tv"
That way, you will see which key is accessed (from which folder), and you can compare both session.这样,您将看到访问了哪个密钥(从哪个文件夹),并且可以比较两个会话。
It looks like in no-admin mode it even do not try to find keys/configs in right location.看起来在无管理员模式下,它甚至不会尝试在正确的位置找到密钥/配置。
What it does look like is, in no-admin mode, there is an environment variable HOME
set to T:\
or /t
.它的样子是,在无管理员模式下,有一个环境变量HOME
设置为T:\
或/t
。
Type set HOME
in a CMD to confirm.在 CMD 中键入set HOME
进行确认。
Setting that variable to %USERPROFILE%
would mean using the right path.将该变量设置为%USERPROFILE%
意味着使用正确的路径。
声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.