将 gitlab ssh 公钥添加到公司防火墙后面 dockerfile 中的已知主机（无端口 22）

Question

我正在尝试在 docker 构建过程中的 known_hosts 文件中识别公钥，我正在使用的 dockerfile 的相关部分是这样的：

RUN mkdir -p -m 0700 ~/.ssh

# Copy SSH host config to use port 443
COPY docker/config/gitlab_host.txt /root/.ssh/config

RUN cat ~/.ssh/config

# Download public key for gitlab.com
RUN ssh-keyscan -p443 gitlab.com >> ~/.ssh/known_hosts
RUN cat ~/.ssh/known_hosts

为了补全，ssh配置文件（docker/config/gitlab_host.txt）：

Host gitlab.com
  Hostname altssh.gitlab.com
  User git
  Port 443
  PreferredAuthentications publickey
  IdentityFile ~/.ssh/id_rsa

首先，我在企业防火墙后面，端口 22 上没有出站流量。因此，我们将 ssh 配置配置为使用端口 443，幸好 gitlab 提供了此选项。但是，ssh-keyscan 似乎不支持此配置，指定此端口似乎也不起作用，ssh-keyscan 部分只是静默失败。我已经尝试了命令的多种排列：

ssh-keyscan -p 443 gitlab.com ssh-keyscan gitlab.com:443

一切都无济于事。为详细程度提供 -v 标志也不会生成输出。

我能想到的唯一其他选择是复制到我自己的 known_hosts 文件中，这是否有效并且安全吗？存储库的实际克隆是通过“传递”主机 ssh 来完成的。

RUN --mount=type=ssh,uid=1001 pip install git+ssh://git@gitlab.com/<private>.git
RUN --mount=type=ssh,uid=1001 pip install git+ssh://git@gitlab.com/<another_private>.git

我必须通过什么选项让主机知道以便我可以 git clone？

Answer 1

我也注意到了这个问题。

当我尝试使用ssh-keyscan -p 443 altssh.gitlab.com 获取公钥时，它会静默停止，-vv 的详细模式也不会提供太多信息。

我什至尝试通过nmap 获取公钥，但它似乎也不起作用：

Starting Nmap 7.80 ( https://nmap.org ) at 2021-10-20 17:09 CEST
NSE: Loaded 1 scripts for scanning.
NSE: Script Pre-scanning.
NSE: Starting runlevel 1 (of 1) scan.
Initiating NSE at 17:09
Completed NSE at 17:09, 0.00s elapsed
Warning: Hostname altssh.gitlab.com resolves to 26 IPs. Using 172.65.251.182.
Initiating Ping Scan at 17:09
Scanning altssh.gitlab.com (172.65.251.182) [2 ports]
Completed Ping Scan at 17:09, 0.00s elapsed (1 total hosts)
Initiating Parallel DNS resolution of 1 host. at 17:09
Completed Parallel DNS resolution of 1 host. at 17:09, 1.01s elapsed
Initiating Connect Scan at 17:09
Scanning altssh.gitlab.com (172.65.251.182) [1 port]
Discovered open port 443/tcp on 172.65.251.182
Completed Connect Scan at 17:09, 0.00s elapsed (1 total ports)
NSE: Script scanning 172.65.251.182.
NSE: Starting runlevel 1 (of 1) scan.
Initiating NSE at 17:09
Completed NSE at 17:09, 0.00s elapsed
Nmap scan report for altssh.gitlab.com (172.65.251.182)
Host is up, received syn-ack (0.0020s latency).
Other addresses for altssh.gitlab.com (not scanned): 172.64.33.173 173.245.59.173 108.162.193.173 173.245.58.77 108.162.192.77 172.64.32.77 173.245.59.173 108.162.193.173 172.64.33.173 108.162.192.77 172.64.32.77 173.245.58.77 2a06:98c1:50::ac40:21ad 2606:4700:58::adf5:3bad 2803:f800:50::6ca2:c1ad 2606:4700:50::adf5:3a4d 2803:f800:50::6ca2:c04d 2a06:98c1:50::ac40:204d 2606:4700:90:0:f0ff:e6a3:2ac:f7ef 2606:4700:58::adf5:3bad 2803:f800:50::6ca2:c1ad 2a06:98c1:50::ac40:21ad 2803:f800:50::6ca2:c04d 2a06:98c1:50::ac40:204d 2606:4700:50::adf5:3a4d
Scanned at 2021-10-20 17:09:01 CEST for 1s

PORT    STATE SERVICE REASON
443/tcp open  https   syn-ack

NSE: Script Post-scanning.
NSE: Starting runlevel 1 (of 1) scan.
Initiating NSE at 17:09
Completed NSE at 17:09, 0.00s elapsed
Read data files from: /usr/bin/../share/nmap
Nmap done: 1 IP address (1 host up) scanned in 1.19 seconds

另外，我备份了我的known_hosts 文件，并通过 SSH 访问了altssh.gitlab.com:443，以查看指纹是如何保存的，令我惊讶的是主机，而不是保存为altssh.gitlab.com 存储为[altssh.gitlab.com]：

我可以用ssh-keygen -H -F '[altssh.gitlab.com]:443' 找到它，但不是ssh-keygen -H -F altssh.gitlab.com:443，这是正常的方式。

我不知道这种行为的原因，但我知道 OpenSSH 7.6 包含一个用于在第一次尝试时添加新主机密钥的新标志，所以我只做一次：

ssh -oStrictHostKeyChecking=accept-new -p 443 git@altssh.gitlab.com

来自man ssh_config的文档：

If this flag is set to “accept-new” then ssh will automatically
add new host keys to the user known hosts files, but will not
permit connections to hosts with changed host keys.

它将失败并且实际上不会执行连接，因为我没有提供任何身份验证方法，但 HostKey 将存储在 known_hosts 中，从那时起，您将能够使用当前配置进行访问.