这是我的情况:我正在建立一个测试工具,它将从中央客户端启动多个虚拟机实例,然后通过ssh在它们上执行命令。虚拟机将具有以前未使用的主机名和IP地址,因此它们将不在中央客户端的~/.ssh/known_hosts文件中。

我遇到的问题是,第一个ssh命令针对新的虚拟实例总是带有交互式提示: ,也许通过使用已经包含在虚拟机映像中的公共密钥?如果可以的话,我真的希望避免使用Expect或其他方式来回答交互式提示。

评论

对于独立且物理安全的测试环境,自动密钥接受可能会很好。但是,在生产环境中或在不受信任的网络(例如Internet)上自动接受公钥将完全绕过SSH所无法提供的针对中间人攻击的保护。确保您不受MITM攻击侵害的唯一有效方法是通过某些带外可信通道来验证主机的公钥。没有建立适度复杂的密钥签名基础结构,就没有安全的方法来自动化它。

#1 楼

在配置文件中或通过StrictHostKeyCheckingno选项设置为-o

ssh -o StrictHostKeyChecking=no username@hostname.com

评论


这会使您在中间攻击时对人开放,这可能不是一个好主意。

–贾斯珀·华莱士(JasperWallace)
2013年9月23日在7:23

@JasperWallace,尽管通常这是一个好建议,但特定的用例(部署测试VM并向其发送命令)应该足够安全。

–马西莫
2014年10月21日在17:33

这给出了警告:将“ hostname,1.2.3.4”(RSA)永久添加到已知主机列表中。为避免警告,并避免将条目添加到任何known_hosts文件,我这样做:ssh -o StrictHostKeyChecking = no -o LogLevel = ERROR -o UserKnownHostsFile = / dev / null username@hostname.com

– Peter V.Mørch
2015年5月21日在9:19



拒绝投票不能解决问题,并且会带来严重的安全漏洞。

– marcv81
16年1月20日在4:48

@Mnebuerquo:如果您担心安全性,那么这个问题将与您毫无关系。您前面有正确的主机密钥,该主机密钥是从您要连接的系统的控制台收集的,并且在首次连接时需要手动进行验证。您当然不会“自动”执行任何操作。

–伊格纳西奥·巴斯克斯(Ignacio Vazquez-Abrams)
16年6月15日在17:31

#2 楼

IMO,执行此操作的最佳方法如下:

ssh-keygen -R [hostname]
ssh-keygen -R [ip_address]
ssh-keygen -R [hostname],[ip_address]
ssh-keyscan -H [hostname],[ip_address] >> ~/.ssh/known_hosts
ssh-keyscan -H [ip_address] >> ~/.ssh/known_hosts
ssh-keyscan -H [hostname] >> ~/.ssh/known_hosts


这将确保没有重复的条目,并且主机名和IP地址都已覆盖,还将散列输出,这是一种额外的安全措施。

评论


为什么需要全部3个ssh-keyscan?您不能只使用第一个,因为它同时适用于主机名和ip吗?

–罗伯特
13年5月24日22:00

您是否可以确定回复ssh-keyscan请求的机器确实是您要与之对话的机器?如果不是,您就向中间攻击者敞开大门。

–贾斯珀·华莱士(JasperWallace)
2013年9月23日7:24



@JasperWallace是的,为此,您至少需要指纹甚至更好的公钥,在这种情况下,您可以将其直接添加到known_hosts,从而解决这个问题。如果只有指纹,则必须写一个额外的步骤,用指纹来验证下载的公钥。

–user68729
2014年4月28日在21:57

调用ssh-keyscan失败,因为我的目标主机不支持默认的版本1密钥类型。在命令中添加-t rsa,dsa可以解决此问题。

– phasetwenty
2014年8月6日18:11

这可能是一个坏主意。通过更新这些密钥,您正对中间人攻击开放。为避免重复输入,请改为检查ssh-keygen -F [地址]的返回状态。 medium.com/@wblankenship/…

– retrohacker
2015年9月29日在3:04



#3 楼

对于懒惰的用户:

ssh-keyscan -H <host> >> ~/.ssh/known_hosts


-H哈希主机名/ IP地址

评论


易受MITM攻击。您没有检查钥匙指纹。

– Mnebuerquo
16年6月15日在17:20

@Mnebuerquo您说该怎么做,但不能说怎么做,这会有所帮助。

–雷
17 Mar 24 '17 at 21:20

@jameshfisher是的,它很容易受到MITM攻击,但是您是否曾经将RSA指纹(当您手动执行此操作时,与实际的一台服务器相比)进行了比较?没有?因此,此答案就是为您完成此任务的方法。如果是,则不应使用此答案,而应手动执行或采取其他安全措施...

–五
17年11月30日在9:07



@Mnebuerquo,如果您还让我们知道一种更好的方式来处理此问题,当我们需要使用无人看管的批处理脚本克隆存储库并且希望绕过此提示时,我将非常高兴。如果您认为这不是正确的解决方案,请提供一些实际解决方案!

–赛义德·瓦卡斯(Syed Waqas)
18年1月4日在4:22

BradChesney79的回答在任何意义上都不是一种更好的方法。从字面上看,他所做的所有工作都是使用nmap获取SSH主机密钥指纹,然后将其与ssh-keyscan所说的指纹进行比较。在这两种情况下,指纹都来自同一位置。与其他任何自动化解决方案一样,它也容易受到MITM的攻击。验证SSH公钥的唯一安全有效方法是通过某些受信任的带外通道。 (或建立某种类型的密钥签名基础结构。)

– Eil
18-2-15在19:52



#4 楼

如前所述,使用按键扫描将是正确且毫不干扰的方法。

ssh-keyscan -t rsa,dsa HOST 2>&1 | sort -u - ~/.ssh/known_hosts > ~/.ssh/tmp_hosts
mv ~/.ssh/tmp_hosts ~/.ssh/known_hosts


上面的方法可以成功添加主机,只有在主机具有尚未添加。它也不是并发安全的。您不得在同一原始计算机上同时执行该代码段,因为tmp_hosts文件可能会被破坏,从而最终导致known_hosts文件变得肿...

评论


有没有办法在ssh-keyscan之前检查密钥是否在known_hosts中?原因是它需要一些时间和额外的网络连接。

– utapyngo
2014年5月23日7:49

此文件的原始发布者版本的目录为cat〜/ .ssh / tmp_hosts>〜/ .ssh / known_hosts,但随后的编辑将其更改为>>。使用>>是错误。它破坏了第一行中唯一性的目的,并使其在每次运行时都将新条目转储到known_hosts中。 (只需发布修改内容即可将其改回。)

–paulmelnikow
15年7月27日在17:46



这会遭受与其他相同的MITM攻击。

– Mnebuerquo
16年6月15日在17:18

@utapyngo ssh-keygen -F将为您提供当前指纹。如果返回空白,返回码为1,则说明您没有。如果它打印出一些东西,并且返回码为0,则说明它已经存在。

– Rich L
17年8月17日在13:58

如果您非常关心MITM,请部署DNSSEC和SSHFP记录,或使用其他一些安全的方式分发密钥,而这种麻烦的解决方案将是无关紧要的。

– Zart
17年11月28日在17:09

#5 楼

您可以使用ssh-keyscan命令来获取公钥并将其附加到您的known_hosts文件中。

评论


确保检查指纹以确保它是正确的密钥。否则,您可能会遭受MITM攻击。

– Mnebuerquo
16年6月15日在17:20

@Mnebuerquo一般情况下的公平点,但是如果有人已经知道正确的密钥是什么,为什么有人会尝试以编程方式收集密钥?

–布莱恩·克莱恩(Brian Cline)
17年8月25日在19:27



这不是这样做的方法。 MITM。

– Jameshfisher
17年11月28日在16:39

#6 楼

这将是一个完整的解决方案,仅第一次接受主机密钥。

#!/usr/bin/env ansible-playbook
---
- name: accept ssh fingerprint automatically for the first time
  hosts: all
  connection: local
  gather_facts: False

  tasks:
    - name: "check if known_hosts contains server's fingerprint"
      command: ssh-keygen -F {{ inventory_hostname }}
      register: keygen
      failed_when: keygen.stderr != ''
      changed_when: False

    - name: fetch remote ssh key
      command: ssh-keyscan -T5 {{ inventory_hostname }}
      register: keyscan
      failed_when: keyscan.rc != 0 or keyscan.stdout == ''
      changed_when: False
      when: keygen.rc == 1

    - name: add ssh-key to local known_hosts
      lineinfile:
        name: ~/.ssh/known_hosts
        create: yes
        line: "{{ item }}"
      when: keygen.rc == 1
      with_items: '{{ keyscan.stdout_lines|default([]) }}'


评论


这不是这样做的方法。 MITM。

– Jameshfisher
17年11月28日在16:40

#7 楼

这是将ssh-keyscan整合到游戏中的方法:

---
# ansible playbook that adds ssh fingerprints to known_hosts
- hosts: all
  connection: local
  gather_facts: no
  tasks:
  - command: /usr/bin/ssh-keyscan -T 10 {{ ansible_host }}
    register: keyscan
  - lineinfile: name=~/.ssh/known_hosts create=yes line={{ item }}
    with_items: '{{ keyscan.results | map(attribute='stdout_lines') | list }}'


评论


您是否正在上载一个有效的已知known_hosts文件,或者正在执行ssh-keyscan并将输出转储到known_hosts中而不验证指纹?

– Mnebuerquo
16年6月15日在17:22

这只是转储按键扫描的输出,是的。因此,实际上,它与StrictHostKeyChecking = no相同,只是在无提示的情况下更新了known_hosts而没有摆弄ssh选项。由于ssh-keyscan返回多行,因此该解决方案也不起作用,这导致该任务始终被标记为“已更改”

– Zart
16年6月16日在21:42

这不是这样做的方法。 MITM。

– Jameshfisher
17年11月28日在16:39

@jameshfisher如果您还需要让我们知道一种更好的方法来处理此问题,当我们需要使用无人看管的批处理脚本克隆存储库并且希望绕过此提示时,我将非常高兴。如果您认为这不是正确的解决方案,请提供一些实际解决方案!如果您认为这样做不是正确的方法,请告诉我们“怎么做”!

–赛义德·瓦卡斯(Syed Waqas)
18年1月4日在4:25

这是将值添加到known_hosts的一种非常有效的方法,但是是的,它容易受到MITM的影响。但是,供内部使用是可以的。

– Cameron Lowell Palmer
18年11月23日在14:15

#8 楼

我使用digbash编写了一个单行脚本,该脚本有点长,但对于使具有多个IP的主机执行此任务很有用

#9 楼

我遇到了类似的问题,发现提供的某些答案仅使我成为自动化解决方案的一部分。以下是我最终使用的内容,希望对您有所帮助:

ssh -o "StrictHostKeyChecking no" -o PasswordAuthentication=no 10.x.x.x


它将密钥添加到known_hosts,并且不提示输入密码。

评论


易受MITM攻击。您没有检查指纹。

– Mnebuerquo
16年6月15日在17:23

没有人检查指纹。

–布兰登·伯德(Brendan Byrd)
17-6-27 at 3:11

这不是这样做的方法。 MITM。

– Jameshfisher
17年11月28日在16:40

#10 楼

为了正确执行此操作,您真正想要做的是在创建VM时收集VM的主机公共密钥,并将它们放入known_hosts格式的文件中。然后,可以使用指向该文件的-o GlobalKnownHostsFile=...来确保要连接到您认为应该连接的主机。如何执行此操作取决于您如何设置虚拟机,但是,如果可能的话,请从虚拟文件系统中读取它,或者甚至让主机在配置过程中打印/etc/ssh/ssh_host_rsa_key.pub的内容。

话虽如此,这可能不值得,这取决于您所处的环境以及预期的对手是谁。如上面其他几个答案所述,进行简单的“首次连接存储”(通过扫描或仅在第一个“实际”连接期间进行存储)可能会变得相当容易,并且仍然提供一定程度的安全性。但是,如果这样做,强烈建议您将用户已知的主机文件(-o UserKnownHostsFile=...)更改为特定于该特定测试安装的文件。这样可以避免用测试信息污染您的个人已知主机文件,并在删除VM时轻松清除现在无用的公钥。

#11 楼

以下避免〜/ .ssh / known_hosts中的重复条目:

if ! grep "$(ssh-keyscan github.com 2>/dev/null)" ~/.ssh/known_hosts > /dev/null; then
    ssh-keyscan github.com >> ~/.ssh/known_hosts
fi


评论


这不是这样做的方法。 MITM。

– Jameshfisher
17年11月28日在16:42

我最喜欢这个答案。对于脚本化的初始VPS脚本,除了我以外,对其他任何人都不重要,MITM的风险正在逐渐减小。无穷小怪癖...第一行需要是mkdir -p〜/ .ssh / known_hosts;

–马丁·布拉姆威尔
19 Mar 5 '19在23:00

#12 楼

您如何建造这些机器?您可以运行dns更新脚本吗?您可以加入IPA域吗?

FreeIPA会自动执行此操作,但实际上您所需要的只是您区域上的SSHFP dns记录和DNSSEC(freeipa作为可配置选项提供(默认为dnssec禁用))。 />
可以通过运行从主机获取现有的SSHFP记录。

ssh-keygen -r jersey.jacobdevans.com


jersey.jacobdevans.com在SSHFP中1 1 4d8589de6b1a48e148d8fc9fbb967f1b29f53ebc jersey.jacobdevans.com IN SSHFP 1 2 6503272a11ba6d7fec2518c02dfed88f3d455ac7786ee5dbd72df63307209d55
jersey.jacobdevans.com IN SSHFP 3 1 5a7a1e8ab8f25b86b63c377b303659289b895736> jersey.jacobdevans.com IN SSHFP 3 2 1f50f790117dfedd329dbcf622a7d47551e12ff5913902c66a7da28e47de4f4b


然后一旦发布,您可以将VerifyHostKeyDNS yes添加到ssh_config或〜/ .ssh / config

如果/当Google决定启用DNSSEC时,您可以在没有主机密钥提示的情况下ssh进入。

ssh jersey.jacobdevans.com

但是我的域尚未签名,所以现在您将看到....

debug1:服务器主机密钥:ecdsa-sha2-nistp256 SHA256:H1D3kBF9 / t0ynbz2IqfUdVHhL / WROQLGan2ijkfeT0s

debug1:在DNS中找到4个不安全的指纹

debug1:匹配主机密钥在DNS中发现指纹

无法建立主机'jersey.jacobdevans.com(2605:6400:10:434 :: 10)的真实性。 ECDSA密钥指纹为
SHA256:H1D3kBF9 / t0ynbz2IqfUdVHhL / WROQLGan2ijkfeT0s。在DNS中找到匹配的主机密钥指纹。您确定要继续连接(是/否)吗?否


#13 楼

因此,我正在寻找一种平凡的方法来绕过克隆git repo的未知主机手动交互,如下所示:

brad@computer:~$ git clone git@bitbucket.org:viperks/viperks-api.git
Cloning into 'viperks-api'...
The authenticity of host 'bitbucket.org (104.192.143.3)' 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)?


请注意RSA密钥指纹...

所以,这是一个SSH东西,它将在SSH上适用于git,并且通常只与SSH相关的东西...

brad@computer:~$ nmap bitbucket.org --script ssh-hostkey

Starting Nmap 7.01 ( https://nmap.org ) at 2016-10-05 10:21 EDT
Nmap scan report for bitbucket.org (104.192.143.3)
Host is up (0.032s latency).
Other addresses for bitbucket.org (not scanned): 104.192.143.2 104.192.143.1 2401:1d80:1010::150
Not shown: 997 filtered ports
PORT    STATE SERVICE
22/tcp  open  ssh
| ssh-hostkey:
|   1024 35:ee:d7:b8:ef:d7:79:e2:c6:43:9e:ab:40:6f:50:74 (DSA)
|_  2048 97:8c:1b:f2:6f:14:6b:5c:3b:ec:aa:46:46:74:7c:40 (RSA)
80/tcp  open  http
443/tcp open  https

Nmap done: 1 IP address (1 host up) scanned in 42.42 seconds


首先,在日常驱动程序上安装nmap。 nmap在某些方面非常有用,例如检测打开的端口以及手动验证SSH指纹。但是,回到我们正在做的事情。

很好。我要么在检查过的多个位置和机器上受到损害,要么正在对一切都是“笨拙”进行更合理的解释。

“指纹”只是一个字符串的缩写采用一种单向算法为人类带来便利,但存在多个字符串分解为同一指纹的风险。碰巧的是,它们称为碰撞。

无论如何,回到我们在下面的上下文中可以看到的原始字符串。

brad@computer:~$ ssh-keyscan bitbucket.org
# bitbucket.org SSH-2.0-conker_1.0.257-ce87fba app-128
no hostkey alg
# bitbucket.org SSH-2.0-conker_1.0.257-ce87fba app-129
bitbucket.org ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAubiN81eDcafrgMeLzaFPsw2kNvEcqTKl/VqLat/MaB33pZy0y3rJZtnqwR2qOOvbwKZYKiEO1O6VqNEBxKvJJelCq0dTXWT5pbO2gDXC6h6QDXCaHo6pOHGPUy+YBaGQRGuSusMEASYiWunYN0vCAI8QaXnWMXNMdFP3jHAJH0eDsoiGnLPBlBp4TNm6rYI74nMzgz3B9IikW4WVK+dc8KZJZWYjAuORU3jc1c/NPskD2ASinf8v3xnfXeukU0sJ5N6m5E8VLjObPEO+mN2t/FZTMZLiFqPWc/ALSqnMnnhwrNi2rbfg/rd/IpL8Le3pSBne8+seeFVBoGqzHM9yXw==
# bitbucket.org SSH-2.0-conker_1.0.257-ce87fba app-123
no hostkey alg


提前,我们有一种方法可以要求原始主机提供某种形式的标识。

此时,我们手动地像自动地一样容易受到攻击-字符串匹配,我们拥有基本数据创建指纹,然后我们可以在将来请求该基础数据(防止冲突)。

现在以防止询问主机真实性的方式使用该字符串...

在这种情况下,known_hosts文件不使用纯文本条目。当您看到哈希条目时,您会知道它们看起来像是带有随机字符的哈希,而不是xyz.com或123.45.67.89。会显示-但您可以通过“>”或“ >>”约定通过简单的重定向来摆脱它。

在尽我最大的努力来获取用于标识“主机”和信任的无污染数据时,我会将这个标识添加到我的〜/ .ssh目录中的known_hosts文件中。由于现在它已被识别为已知的主机,所以当您还是我的时候,我不会收到上面提到的提示。我添加了bitbucket RSA密钥,以便可以作为CI工作流的一部分以非交互方式与我的git存储库进行交互,但是无论您做什么,都可以。

brad@computer:~$ ssh-keyscan -t rsa -H bitbucket.org
# bitbucket.org SSH-2.0-conker_1.0.257-ce87fba app-128
|1|yr6p7i8doyLhDtrrnWDk7m9QVXk=|LuKNg9gypeDhfRo/AvLTAlxnyQw= ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAubiN81eDcafrgMeLzaFPsw2kNvEcqTKl/VqLat/MaB33pZy0y3rJZtnqwR2qOOvbwKZYKiEO1O6VqNEBxKvJJelCq0dTXWT5pbO2gDXC6h6QDXCaHo6pOHGPUy+YBaGQRGuSusMEASYiWunYN0vCAI8QaXnWMXNMdFP3jHAJH0eDsoiGnLPBlBp4TNm6rYI74nMzgz3B9IikW4WVK+dc8KZJZWYjAuORU3jc1c/NPskD2ASinf8v3xnfXeukU0sJ5N6m5E8VLjObPEO+mN2t/FZTMZLiFqPWc/ALSqnMnnhwrNi2rbfg/rd/IpL8Le3pSBne8+seeFVBoGqzHM9yXw==


所以,这就是您今天仍然处女的方式。您可以通过按照自己的时间遵循类似的指示来对github进行相同的操作。

我看到了很多堆栈溢出帖子,告诉您以编程方式盲目添加密钥,而无需进行任何检查。您检查来自不同网络上不同计算机的密钥的次数越多,您对主机就是它所说的主机的信任就越多-这就是您希望从此安全性层得到的最好的证明。

WRONG
ssh -oStrictHostKeyChecking =无主机名[命令]

WRONG
ssh-keyscan -t rsa -H主机名>>〜/ .ssh / known_hosts

请不要执行以上任何一项操作。您有机会增加自己的机会,避免有人通过中间攻击者偷听您的数据传输,抓住这个机会。区别在于从字面上验证您拥有的RSA密钥是真正的服务器之一,现在您知道如何获取该信息以进行比较,以便您可以信任连接。请记住,来自不同计算机和网络的更多比较通常会提高您信任连接的能力。

评论


我认为这是解决此问题的最佳方法。但是,在Amazon EC2之类的设备上使用Nmap时要非常小心,我收到有关Nmap进行端口扫描的警告!进行portcanning之前,请填写其表单!

–赛义德·瓦卡斯(Syed Waqas)
18年1月5日在4:37

嗯,是的我不知道为什么要从EC2进行端口扫描。如果您登录到帐户,则只能从实际计算机上获取密钥。对于您无法控制的机器,这更多。我假设您将拥有一台不受AWS端口扫描限制的本地计算机。但是,如果您处于这种极端情况下,必须使用AWS运行nmap,我想这个警告会有所帮助。

–BradChesney79
18年1月15日在19:51

使用nmap从您的工作站读取SSH主机密钥,然后信任该值与在关闭了StructHostKeyChecking的情况下通过SSH连接没有什么不同。它同样容易受到中间人攻击。

– Micah R Ledbetter
18年2月7日在17:40

... @ MicahRLedbetter,这就是为什么我建议“来自不同计算机和网络的更多比较通常会提高您信任连接的能力”的原因。但是,这就是我的意思。如果您只从一组环境条件中检查目标主机,那么您将如何知道任何差异?您有更好的建议吗?

–BradChesney79
18年2月7日在19:06

这是安全剧院。做一些复杂的事情以创建更高安全性的外观。您可以使用多少种不同的方法来询问主机的密钥,这无关紧要。就像多次询问同一个人是否可以信任他们(也许您打电话,发电子邮件,发短信和蜗牛邮件一样)。他们总是会说“是”,但是如果您问错人了,那就没关系了。

–vastlysuperiorman
18年6月26日在17:28

#14 楼

这整个


ssh-key-scan
ssh-copy-id
ECSDA键警告

业务一直让我烦恼,所以我选择了对于

一个脚本将它们全部统治

这是https://askubuntu.com/a/949731/129227上脚本的变体,其中Amadu Bah的回答为https: //循环中的serverfault.com/a/858957/162693。

示例调用

./sshcheck somedomain site1 site2 site3

该脚本将遍历名称站点并修改.ssh / config和。 ssh / known_hosts文件,并根据要求执行ssh-copy-id-对于最后一项功能,只是让ssh测试调用失败,例如通过在密码请求中按回车3次。

#15 楼

检查每个新服务器/主机的指纹。这是认证服务器的唯一方法。没有它,您的SSH连接可能会受到中间人的攻击。<​​br />
不要使用旧的值StrictHostKeyChecking=no,它根本不会检查服务器的真实性。虽然StrictHostKeyChecking=no的含义将在以后翻转。

第二个选项,但不太安全,是使用StrictHostKeyChecking=accept-new,它是OpenSSH 7.6(2017-10-03)版本中引入的:


第一个“ accept-new”将自动接受
迄今未见过的密钥,但拒绝更改或无效的主机密钥的连接。


#16 楼

这是如何进行主机的收集

定义主机的收集

ssh_hosts:
  - server1.domain.com
  - server2.domain.com
  - server3.domain.com
  - server4.domain.com
  - server5.domain.com
  - server6.domain.com
  - server7.domain.com
  - server8.domain.com
  - server9.domain.com


然后定义两个任务以将密钥添加到已知主机:

- command: "ssh-keyscan {{item}}"
   register: known_host_keys
   with_items: "{{ssh_hosts}}"
   tags:
     - "ssh"

 - name: Add ssh keys to know hosts
   known_hosts:
     name: "{{item.item}}"
     key: "{{item.stdout}}"
     path: ~/.ssh/known_hosts
   with_items: "{{known_host_keys.results}}"


#17 楼

如果希望在盲目添加之前检查密钥,可以使用以下代码:

 # verify github and gitlab key
# GitHub
github=SHA256:nThbg6kXUpJWGl7E1IGOCspRomTxdCARLviKw6E5SY8
ssh-keyscan github.com >> githubKey
read bit githubkey host <<< $(ssh-keygen -lf githubKey)
if [ "$githubkey" != "$github" ]
then
  echo "The GitHub fingerprint is incorrect"
  exit 1
fi
echo "github.com ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAq2A7hRGmdnm9tUDbO9IDSwBK6TbQa+PXYPCPy6rbTrTtw7PHkccKrpp0yVhp5HdEIcKr6pLlVDBfOLX9QUsyCOV0wzfjIJNlGEYsdlLJizHhbn2mUjvSAHQqZETYP81eFzLQNnPHt4EVVUh7VfDESU84KezmD5QlWpXLmvU31/yMf+Se8xhHTvKSCZIFImWwoG6mbUoWf9nzpIoaSjB+weqqUUmpaaasXVal72J+UX2B+2RPW3RcT0eOzQgqlJL3RKrTJvdsjE3JEAvGq3lGHSZXy28G3skua2SmVi/w4yCE6gbODqnTWlg7+wC604ydGXA8VJiS5ap43JXiUFFAaQ==" | sudo tee -a /etc/ssh/ssh_known_hosts

# GitLab
gitlab=SHA256:ROQFvPThGrW4RuWLoL9tq9I9zJ42fK4XywyRtbOz/EQ
ssh-keyscan gitlab.com >> gitlabKey
read bit gitlabkey host <<< $(ssh-keygen -lf gitlabKey)
if [ "$githubkey" != "$github" ]
then
  echo "The GitLab fingerprint is incorrect"
  exit 1
fi
echo "gitlab.com ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCsj2bNKTBSpIYDEGk9KxsGh3mySTRgMtXL583qmBpzeQ+jqCMRgBqB98u3z++J1sKlXHWfM9dyhSevkMwSbhoR8XIq/U0tCNyokEi/ueaBMCvbcTHhO7FcwzY92WK4Yt0aGROY5qX2UKSeOvuP4D6TPqKF1onrSzH9bx9XUf2lEdWT/ia1NEKjunUqu1xOB/StKDHMoX4/OKyIzuS0q/T1zOATthvasJFoPrAjkohTyaDUz2LN5JoH839hViyEG82yB+MjcFV5MU3N1l1QL3cVUCh93xSaua1N85qivl+siMkPGbO5xR/En4iEY6K2XPASUEMaieWVNTRCtJ4S8H+9" | sudo tee -a /etc/ssh/ssh_known_hosts
 


如果GitHub和GitLab密钥被泄露,它们可能会更改。在这种情况下,请在此处和此处检查最新的密钥。

备注:您可能需要确保未两次添加密钥。为此,请参考其他答案。

#18 楼

我遇到了类似的问题,尽管使用了上述经过验证的解决方案,但我的ssh无法正常工作,这是因为〜/ .ssh /目录中缺少known_hosts文件,并且文件系统是只读的。因此,在运行时也无法创建〜/ .ssh / known_hosts文件。

如果遇到类似的问题,请查看是否可以在/ tmp位置写入known_hosts文件。即使在只读文件系统中,大多数情况下也可以启用写操作。

稍​​后,在ssh命令中,您可以指定ssh从/ tmp位置读取known_hosts文件。

ssh -o UserKnownHostsFile = / tmp / known_hosts -o StrictHostKeyChecking = no user_name @ destination_server_ip

评论


您的答案不包含以下问题的解决方案:是否可以自动将新主机添加到known_hosts?

–inetknght
12月2日1:32

#19 楼

如果您已经拥有一个.pub,那么任何告诉您有关ssh-keyscan的人都在要求您冒险进行MitM攻击。

我正在建立一个测试工具,它将从中央客户端启动多个虚拟工具。计算机实例,然后通过ssh在它们上执行命令。

来自StackOverflow的答案有一个更好更正确的答案。您必须从可信任的来源获取.pub文件-系统引导程序应调用home并将其提供给管理系统。
#!/usr/bin/env bash

: "${pubkey=-""}"
: "${host=-""}"

TMP_KNOWN_HOSTS=$(mktemp)
echo "${host}" "$(cat "${pubkey}")" > "${TMP_KNOWN_HOSTS}"

ssh-keygen -H -f "${TMP_KNOWN_HOSTS}"
ssh-keygen -F "${host}" -f "${TMP_KNOWN_HOSTS}" | tee ~/.ssh/known_hosts

shred "${TMP_KNOWN_HOSTS}.old"
rm -f "${TMP_KNOWN_HOSTS}" "${TMP_KNOWN_HOSTS}.old"

您可以使用本地主机密钥进行尝试: $ for pubkey in /etc/ssh/ssh_host_*.pub; do ./add_pubkey localhost "${pubkey}"; done

#20 楼

这是我的特例:
我正在创建一个Fabric 2.5脚本,以将网站部署到新站点上。某一时刻,它将创建一个ssh密钥,并使用其api将公共密钥添加到gitlab中。然后,它将克隆一个存储库(包含网站源代码)。
脚本中的clone命令失败,当我进入服务器并手动启动该命令时,系统出现The authenticity of host 'host.com ()' can't be established. Are you sure you want to continue connecting (yes/no)?提示符。
首先,我的解决方案是搜索如何自动接受它,但是出于安全考虑,我在pty=True函数中添加了c.run("command") arg,在执行脚本的过程中可以访问该错误。

评论


您的答案不包含以下问题的解决方案:是否可以自动将新主机添加到known_hosts?

–inetknght
12月2日,下午1:31

它包括问题的解决方案问题是,针对新虚拟实例运行的第一个ssh命令始终带有交互式提示。有什么方法可以绕过此[...]吗?我通过键入交互式提示结构找到了这个问题,并认为也许出于相同的原因,其他人也会偶然发现此问题。

– sodimel
12月2日12:36