将 ssh 选项传递给 git clone

发布于 2024-12-10 03:02:02 字数 273 浏览 0 评论 0原文

我正在尝试运行 git clone 而不通过 ssh 检查存储库主机的密钥。我可以像这样从 ssh 执行此操作:

ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no user@host

有什么方法可以将相同的 ssh 选项传递给 git clone 命令吗?

编辑:有一个限制,我无法修改 ~/.ssh/config 或该计算机上的任何其他文件。

I'm trying to run git clone without ssh checking the repository host's key. I can do it from ssh like that:

ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no user@host

Is there any way to pass the same ssh options to the git clone command?

Edit: There is a restriction that I can't modify ~/.ssh/config or any other files on that machine.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(8

凉栀 2024-12-17 03:02:02

最近发布的 git 2.3 支持新变量“GIT_SSH_COMMAND”,可用于定义带参数的命令。

GIT_SSH_COMMAND="ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no" git clone user@host

$GIT_SSH_COMMAND 优先于 $GIT_SSH,并且是
由 shell 解释,这允许附加参数
包括在内。

编辑:虽然这回答了所提出的确切问题,但我同意波约曼建议的编辑,以更好地使用过去十年中添加的此选项。

GIT_SSH_COMMAND="ssh -o StrictHostKeyChecking=accept-new" git clone user@host

The recently released git 2.3 supports a new variable "GIT_SSH_COMMAND" which can be used to define a command WITH parameters.

GIT_SSH_COMMAND="ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no" git clone user@host

$GIT_SSH_COMMAND takes precedence over $GIT_SSH, and is
interpreted by the shell, which allows additional arguments to be
included.

Edit: While this answers the exact question that was asked I would agree with the edit that Poyoman suggested to better use this option that was added in the last decade instead.

GIT_SSH_COMMAND="ssh -o StrictHostKeyChecking=accept-new" git clone user@host
养猫人 2024-12-17 03:02:02

指定不同密钥的另一个选项是 git config core.sshCommand 和 git 2.10 + (Q3 2016)。

这是 Boris答案

参见 提交 3c8ede3 (2016 年 6 月 26 日),作者:阮泰Ngọc Duy (pclouds)
(由 Junio C Hamano -- gitster -- 合并于 提交dc21164,2016 年 7 月 19 日)

新的配置变量core.sshCommand已添加到
指定每个存储库使用的 GIT_SSH_COMMAND 值。

$GIT_ASKPASS$GIT_PROXY_COMMAND类似,我们也从
首先配置文件,然后回退到 $GIT_SSH_COMMAND

这对于选择针对目标的不同私钥非常有用
同一主机(例如github)

core.sshCommand:

如果设置了此变量,git fetchgit push 在需要连接到某个服务器时将使用指定的命令而不是 ssh远程系统。
该命令与GIT_SSH_COMMAND环境变量的形式相同,并且在设置环境变量时被覆盖。

这意味着git克隆可以是:

cd /path/to/my/repo
git config core.sshCommand 'ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no' 
# later on
git clone host:repo.git

如果您想将其应用于所有存储库,如user1300959 添加 在注释中,您将使用全局配置。

git config --global core.sshCommand 'ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no'

Another option made to specify different keys is git config core.sshCommand with git 2.10 + (Q3 2016).

This is an alternative to the environment variable described in Boris's answer)

See commit 3c8ede3 (26 Jun 2016) by Nguyễn Thái Ngọc Duy (pclouds).
(Merged by Junio C Hamano -- gitster -- in commit dc21164, 19 Jul 2016)

A new configuration variable core.sshCommand has been added to
specify what value for GIT_SSH_COMMAND to use per repository.

Similar to $GIT_ASKPASS or $GIT_PROXY_COMMAND, we also read from
config file first then fall back to $GIT_SSH_COMMAND.

This is useful for selecting different private keys targetting the
same host (e.g. github)

core.sshCommand:

If this variable is set, git fetch and git push will use the specified command instead of ssh when they need to connect to a remote system.
The command is in the same form as the GIT_SSH_COMMAND environment variable and is overridden when the environment variable is set.

It means the git clone can be:

cd /path/to/my/repo
git config core.sshCommand 'ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no' 
# later on
git clone host:repo.git

If you want to apply that for all repos, as user1300959 adds in the comments, you would use a global configuration.

git config --global core.sshCommand 'ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no'
盛装女皇 2024-12-17 03:02:02

将它们添加到您的 ~/.ssh/config 中:

Host host
    HostName host
    User user
    SshOption1 Value1
    SshOption2 Value2

Host 条目是您在命令行上指定的内容,HostName 是真实的主机名。它们可以相同,Host 条目也可以是别名。如果您未在命令行上指定 user@,则使用 User 条目。

如果您必须在命令行上进行配置,请将 GIT_SSH 环境变量设置为指向包含您的选项的脚本。

Add them to your ~/.ssh/config:

Host host
    HostName host
    User user
    SshOption1 Value1
    SshOption2 Value2

The Host entry is what you’ll specify on the command line, and the HostName is the true hostname. They can be the same, or the Host entry can be an alias. The User entry is used if you do not specify user@ on the command line.

If you must configure this on the command line, set the GIT_SSH environment variable to point to a script with your options in it.

无需解释 2024-12-17 03:02:02

存储库级别配置而不影响系统级别设置

整合已有的答案,我选择以下步骤。这确保配置更改不会影响机器级别,而只会影响正在处理的存储库。在我的例子中这是需要的,因为我的脚本需要在共享的 Bamboo 代理上执行。

  1. 采用 GIT_SSH_COMMAND 方法克隆存储库。

    GIT_SSH_COMMAND="ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no" git clone ssh://url
    
  2. 克隆后,导航到存储库目录。

    cd repo-dir
    
  3. 设置 core.sshCommand 配置,以便所有未来的调用都可以像往常一样使用 git 命令运行,但在内部使用提供的 git 选项。

    git config core.sshCommand 'ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no'
    

Repository level configuration without impacting the system level settings

Consolidating the already available answers, I am choosing the below steps. This ensures that the configuration changes do not impact at the machine level, but just for the repository being worked on. This is needed in my case as my script needs to be executed on a shared Bamboo agent.

  1. Clone the repository taking the GIT_SSH_COMMAND approach.

    GIT_SSH_COMMAND="ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no" git clone ssh://url
    
  2. Once cloned, navigate into repository directory.

    cd repo-dir
    
  3. Set core.sshCommand configuration so that all future calls can be just run with git commands like usual, but internally consuming the provided git options.

    git config core.sshCommand 'ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no'
    
街角卖回忆 2024-12-17 03:02:02

下面是如何使用 GIT_SSH 变量传递 ssh 参数的棘手示例:

$ echo 'ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no $*' > ssh
$ chmod +x ssh
$ GIT_TRACE=1 GIT_SSH="$PWD/ssh" git clone user@host

注意:上面的行是终端命令行,您应该将其粘贴到终端中。它将创建一个文件ssh,使其可执行并执行它。

如果您想传递私钥选项,请检查如何告诉 git 使用哪个私钥?

Here is tricky example how to pass the ssh arguments by using GIT_SSH variable:

$ echo 'ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no $*' > ssh
$ chmod +x ssh
$ GIT_TRACE=1 GIT_SSH="$PWD/ssh" git clone user@host

Note: Above lines are terminal command-lines which you should paste into your terminal. It'll create a file ssh, make it executable and executes it.

If you'd like to pass the private key option, please check How to tell git which private key to use?.

倚栏听风 2024-12-17 03:02:02

我认为将 git 更新到版本 >= 2.3 并使用 GIT_SSH_COMMAND="ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no" git clone user@host 是最好的选择,但是如果不可能,@josh-lee 提供了一个很好的选择,但是请更新您的答案,缩进 ssh 配置文件。

Host host
    HostName host
    StrictHostKeyChecking no
    UserKnownHostsFile /dev/null

I think that update git to an version >= 2.3 and use GIT_SSH_COMMAND="ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no" git clone user@host is the bet option, but if it not possible, @josh-lee gave a good option, but please, update your answer indenting the ssh config file.

Host host
    HostName host
    StrictHostKeyChecking no
    UserKnownHostsFile /dev/null
笑饮青盏花 2024-12-17 03:02:02

更安全的方法是:

git config --global core.sshCommand 'ssh -o StrictHostKeyChecking=accept-new'

这比 StrictHostKeyChecking=no 更安全,因为 accept-new 仍然会对它知道已更改的键产生错误,但不会对其从未更改过的键产生错误以前见过。 no 禁用所有检查。

对于一次性命令,请使用:

git -c core.sshCommand='ssh -o StrictHostKeyChecking=accept-new' clone ...

A safer way is:

git config --global core.sshCommand 'ssh -o StrictHostKeyChecking=accept-new'

This is safer than StrictHostKeyChecking=no because accept-new will still produce an error for keys that it knows have changed, just not for keys it has never seen before. no disables all checking.

For a one-off command use:

git -c core.sshCommand='ssh -o StrictHostKeyChecking=accept-new' clone ...

通过在 Windows 计算机中执行以下步骤已修复此问题:-

  • 在 C:\Users\username.ssh 文件夹下创建配置文件。

  • 将以下行添加到配置文件中。

    主机 ;
    主机名 
    用户
    身份文件 ~/.ssh/id_rsa
    身份只有是
    端口 
    Kex算法 +diffie-hellman-group1-sha1
    
  • 然后再试一次。

This issue has been fixed by doing follow step's in Window machine:-

  • Create config file under C:\Users\username.ssh folder.

  • add the following line to a config file.

    host <HOST>
    hostname <HOSTNAME>
    user <USER_NAME>
    IdentityFile ~/.ssh/id_rsa
    IdentitiesOnly yes
    port <PORT_NUMBER>
    KexAlgorithms +diffie-hellman-group1-sha1
    
  • then try again.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文