我想以非交互方式克隆存储库。克隆时,git要求确认主机的指纹:

The authenticity of host 'bitbucket.org (207.223.240.182)' can't be established.
RSA key fingerprint is 97:8c:1b:f2:6f:14:6b:5c:3b:ec:aa:46:46:74:7c:40.
Are you sure you want to continue connecting (yes/no)? no


每当出现此问题时,我如何强制“是”?我尝试使用yes yes | git clone ...,但是它不起作用。

编辑:
这里是一个解决方案:我可以自动将新主机添加到known_hosts吗? (使用ssh-keyscan将整个内容添加到known_hosts)。

评论

有趣的是,即使在两年后,这个问题也没有正确的答案。 git提示的其他情况很少,例如,如果您尝试通过http克隆并且服务器正在请求basic_auth。如何在非交互模式下执行此操作?

添加-q选项(安静)为我做到了。现在,我一直无法自动执行密码短语。

#1 楼

“ StrictHostKeyChecking no”和“ ssh-keyscan”选项都不安全。如果您坚持使用ssh,则需要在某个时候进行手动指纹验证以避免MiTM攻击。
实际上,您有2种选择:
使用https协议代替git
对于指纹,因为不涉及ssh,所以使用https代替。为了安全起见,您信任操作系统上的根证书installod。如果您使用的是最低限度的映像或Docker,则可能需要安装ca-certificates软件包。
如果您真的想要git + ssh协议
,您真的需要在运行时添加密钥吗?这是不安全的,因为您没有检查指纹,这使您容易受到MiTM攻击。
在运行脚本之前,请从github(在本地计算机上)获取密钥:
ssh-keyscan github.com >> githubKey

/>
ssh-keygen -lf githubKey

并手动对照此页面中列出的内容进行检查(好的,您相信https证书和OpenSSL可以为您带来原始的github网站,但比盲目接受公钥要好得多)。 br />或者(信任相同的https和OpenSSL),您可以像这样:curl -s https://api.github.com/meta | jq ."ssh_key_fingerprints" | grep RSA从https://api.github.com/meta获取它。 (感谢@willscripted进行此操作)
然后,您可以在脚本中添加以下代码对其进行硬编码:
echo '<copy paste the content of 'cat githubKey' on your machine>'  >> ~/.ssh/known_hosts

git clone之前。
GitHub公钥只会更改如果他们认为它受到了破坏(或不够安全)。如果是这种情况,则无论如何您都希望脚本失败。

评论


不幸的是,如果您使用两因素身份验证,则无法使用GitHub进行非交互式HTTPS。

–布雷特·威德迈尔
16年4月13日在13:17

我不明白为什么不这样。我们在这里谈论的是公共回购,无需身份验证。从脚本克隆私有存储库完全是另一回事:您需要授权脚本才能这样做。

–autra
16-4-20在10:44

在现代浏览器(例如Chrome浏览器)中,借助“搜索栏”,“手动”检查指纹比听起来要容易得多。

–于富兰
16年8月24日在3:20

有什么方法可以将“期望的”指纹作为git clone的命令行参数提供,而不必首先将其放在文件中吗?

– FGreg
19年7月25日在16:19

现在可以根据开发人员api中的值验证Github的键扫描指纹。 curl -i https://api.github.com/meta。我们仍然可以信任证书,但是现在是实时的,而不是手动的。

–将
20年6月16日在20:04

#2 楼

我认为这不是最好的解决方案,但这对我来说是一个解决方案。

ANSWER:

使用known_hosts命令将域名添加到ssh-keyscan文件可以解决问题:

ssh-keyscan <enter_domainname_e.g._github.com> >> ~/.ssh/known_hosts

评论


请不要这样。这是完全不安全的:指纹不是在这里惹恼您,而是确保您不会遇到中间人攻击。请在下面查看我的答案。

–autra
2015年10月21日在12:17

正如我所说,“我认为这不是最好的解决方案,但对我来说却是解决方案。”因为我很着急,所以肯定有“正确的方法”(((:

–kroe
2015年10月21日14:05



这不是政治上正确的问题:-)这是一个安全与否的问题。当且仅当您在ssh-keyscan之后并在将其添加到.ssh / known_hosts中并与github在其网站上发布的指纹相同之前手动检查指纹时,您的解决方案才是安全的。您可以通过多种方式来做到这一点,而我就是其中之一。您还可以在脚本中进行相等检查,但最后要解决的是:您需要脚本知道它期望的指纹,并且如果它没有收到正确的指纹,则需要失败。

–autra
2015年11月25日,9:35

仅在不存在时添加密钥ssh-keygen -F github.com || ssh-keyscan github.com >>〜/ .ssh / known_hosts

– Transang
17年5月5日在10:04

在配置管理或预配置运行中执行一次此操作应该很好。如果指纹将来会更改,则ssh将按预期工作,并警告您证书已更改,并返回非0退出代码。这很可能会停止使用ssh或git的任何脚本。

– emhohensee
17年12月23日在19:01

#3 楼

我相信这里更好的选择是备份并清空~/.ssh/known_hosts文件,手动执行SSH连接,验证IP地址和指纹mv ~/.ssh/known_hosts ~/bitbucket_hosts,然后在脚本中使用~/bitbucket_hosts的内容自动将已知指纹添加到known_hosts文件(不要忘记恢复原始~/.ssh/known_hosts)。

此步骤只需要执行一次(我相信可以在任何计算机上执行),并且一旦有了指纹,就可以将其合并到自动化脚本中。

评论


这是最直接的答案。无需编写将指纹生成放入脚本的脚本,而只需建立连接以生成known_hosts文件并在其周围复制known_hosts文件即可

–乔
19年9月19日在18:39

#4 楼

将密钥添加到.ssh/known_hosts似乎是正确的事情。

尽管当您使任务自动化时,您要确保未包含密钥并将其添加到每个clone / pull任务中。 />
如果未找到,此代码段将仅添加指纹:

if [ ! -n "$(grep "^bitbucket.org " ~/.ssh/known_hosts)" ]; then ssh-keyscan bitbucket.org >> ~/.ssh/known_hosts 2>/dev/null; fi


评论


太完美了可以轻松放入部署脚本中,比禁用主机验证更安全。这是github的单行代码:if [! -n“ $(grep” ^ github.com“〜/ .ssh / known_hosts)”];然后ssh-keyscan github.com >>〜/ .ssh / known_hosts 2> / dev / null; fi; ssh-agent bash -c“ ssh-add / path / to / your / deploy / id_rsa; git clone -b master git@github.com:githubAccount / githubRepo.git / your / target / dir

–tweak2
2015年10月14日20:54



在/ etc / ssh / ssh_config(或〜/ .ssh / config)中启用HashKnownHosts时,此功能不起作用。代替 [ ! -n“ $(grep” ^ bitbucket.org“〜/ .ssh / known_hosts)”]最好使用[! “ $(ssh-keygen -F bitbucket.org)”],它可以在known_hosts中找到散列和非散列行。

–克劳斯·康拉德(Claus Conrad)
16-4-22在17:23



#5 楼

虽然我当然知道您想自动化这样的过程,但是这样做是不明智的。使用安全协议时SSH和相关网络子组件不受欢迎的原因是为了警告人们系统的公钥是未知的。这是有意的-用户需要明确告知系统预期的主机。您不想自动接受提供给您的每个公钥,否则SSH或TLS / SSL的部分安全性可能会受到损害。一个示例是通过中间人攻击,例如当代理软件在您期望的主机的位置显示其自己的密钥时。

请谨慎进行。

如果您不担心跨线的代码源,则在克隆时应该显式且排他地使用git://协议-它是无身份验证的明文。

评论


我可以肯定地看到一些用例,其中我们需要强制执行git clone的非交互使用...但这并不意味着我们需要接受任何检查(尤其是指纹检查)。就我而言,我很高兴在这种事情上自动失败。

–vaab
2014年4月11日在11:04

#6 楼

正如杰夫·霍尔(Jeff Hall)所说,这样做是危险的,因为它允许未经检测的中间人攻击。但是,您可以在ssh中使用StrictHostKeyChecking no选项来禁用检查主机密钥。但是,如果我是您,我会非常谨慎地选择该选项。

评论


它还允许中间人吗?

–autra
2015年6月25日15:37