将 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 ，从那时起您将能够使用当前配置进行访问。