gitosis 公钥

gitosis 公钥

在我的客户端上我尝试运行:

git clone gitosis@DevServer:gitosis-admin.git

我收到一个警告:

无法确认主机“10.1.1.13 (10.1.1.13)”的真实性。RSA 密钥指纹为 a2:c3:fd:d7:f7:75:df:dd:49:64:ce:64:cc:98:e6:2c。您确定要继续连接吗(是/否)?

它似乎正在从以下位置获取公钥:

/etc/ssh/ssh_host_rsa_key.pub

我希望它使用位于以下位置的密钥:

/srv/gitosis/.ssh/authorized_keys

我如何让我的服务器分发正确的公钥?

答案1

我认为您可能误解了来自 ssh 的消息。以下...

The authenticity of host '10.1.1.13 (10.1.1.13)' can't be established. RSA key fingerprint is a2:c3:fd:d7:f7:75:df:dd:49:64:ce:64:cc:98:e6:2c. Are you sure you want to continue connecting (yes/no)?

...与您的文件无关authorized_keys。您之所以收到此信息,是因为您之前从未连接到过给定的主机,因此相应的主持人不在您的 inknown_hosts文件中。当您首次连接到远程主机时,这是完全正常的行为(因为在大多数情况下,您不会事先知道相应的主机密钥)。

authorized_keys文件仅供远程主机确定什么是 ssh客户根据连接时提供的私钥来接受连接。

答案2

我可以通过使用以下命令重新初始化管理存储库来解决此问题:

sudo -H -u gitosis gitosis-init < /tmp/id_rsa.pub

这仅在我删除现有存储库后才有效:

sudo rm /srv/gitosis/repositories/gitosis-admin.git -r

重新初始化存储库而不先将其移除不会更新文件authorized_keys。如果您生成了新密钥,那么您将只能使用旧密钥。

答案3

因此,我正在寻找一种普通的方法来绕过未知主机手动交互克隆 git repo,如下所示,它也应该适合您。您看到的指纹来自远程主机提供的密钥。您收到此问题/警告是因为远程主机在您的 known_hosts 文件中没有条目。以下内容将帮助您了解发生了什么:

brad@computer:~$ git clone [email protected]: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。

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==

第一个注释行令人恼火地出现了——但您可以通过“>”或“>>”约定使用简单的重定向来摆脱它。

由于我已尽力获取未受污染的数据以用于识别“主机”和信任,因此我将把此标识添加到我的 ~/.ssh 目录中的 known_hosts 文件中。由于现在它将被识别为已知主机,因此我不会收到上述提示,就像您还是个孩子时一样。

感谢您的支持,现在就开始吧。我正在添加 bitbucket RSA 密钥,以便我可以作为 CI 工作流的一部分以非交互方式与那里的 git 存储库进行交互,但您可以按照自己的意愿进行操作。

#!/bin/bash
cp ~/.ssh/known_hosts ~/.ssh/known_hosts.old && echo "|1|yr6p7i8doyLhDtrrnWDk7m9QVXk=|LuKNg9gypeDhfRo/AvLTAlxnyQw= ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAubiN81eDcafrgMeLzaFPsw2kNvEcqTKl/VqLat/MaB33pZy0y3rJZtnqwR2qOOvbwKZYKiEO1O6VqNEBxKvJJelCq0dTXWT5pbO2gDXC6h6QDXCaHo6pOHGPUy+YBaGQRGuSusMEASYiWunYN0vCAI8QaXnWMXNMdFP3jHAJH0eDsoiGnLPBlBp4TNm6rYI74nMzgz3B9IikW4WVK+dc8KZJZWYjAuORU3jc1c/NPskD2ASinf8v3xnfXeukU0sJ5N6m5E8VLjObPEO+mN2t/FZTMZLiFqPWc/ALSqnMnnhwrNi2rbfg/rd/IpL8Le3pSBne8+seeFVBoGqzHM9yXw==" >> ~/.ssh/known_hosts

所以,这就是你今天保持处女身份的方法。你可以在自己的时间按照类似的指示对 github 做同样的事情。

我看到很多 Stack Overflow 帖子都告诉你,要盲目地以编程方式添加密钥,而无需进行任何检查。你对不同网络上不同机器的密钥检查得越多,你就越能相信主机就是它所说的那个主机——这是你能从这一层安全中获得的最好结果。

错误的 ssh -oStrictHostKeyChecking=no 主机名 [命令]

错误的 ssh-keyscan -t rsa -H 主机名 >> ~/.ssh/known_hosts

请不要做上述任何一件事。您有机会增加避免有人通过中间人攻击窃听您的数据传输的机会——抓住这个机会。区别在于验证您拥有的 RSA 密钥是否是真正的服务器的密钥,现在您知道如何获取该信息来比较它们,以便您可以信任连接。只需记住,从不同的计算机和网络进行更多比较通常会增加您对连接的信任度。

相关内容