GitLab CI 中的 SSH 主机密钥验证失败 [英] SSH Host Key Verification Failed inside GitLab CI

查看:19
本文介绍了GitLab CI 中的 SSH 主机密钥验证失败的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

本地设置

我通过 ssh-keygen 命令创建了一个公共和私有 SSH 密钥.

I created a public and private SSH key via the ssh-keygen command.

我决定先在本地设置私钥,然后在我的 repo 的 gitlab CI 上设置它.

I decided to setup the private key locally first, before setting it up on my repo's gitlab CI.

我在服务器上设置了公钥(在这种情况下,是另一个 gitlab 存储库,但这可能会在未来发生变化并且不应该影响问题).

I setup the public key on the server (in this case, another gitlab repo, but this may change in the future and shouldn't affect the question).

我通过以下命令在本地成功地与服务器通信(在这种情况下,我通过 git 使用 SSH,但将来可能会再次更改):

I successfully communicated with the server locally via the following command (in this case I am using SSH via git, but this again may change in the future):

git clone git@gitlab.com:...../......git

GitLab CI 设置

然后我决定在 gitlab CI 上设置私钥和通信.

I then decided to setup the private key and communication on gitlab CI.

在我的仓库中,我导航到设置 -> 持续集成 -> 变量,并添加了以下环境变量:

Inside my repo, I navigated to Settings -> Continuous Integration -> Variables, and added the following environment variables:

  • SSH_DEPLOY_PRIVATE_KEY - 我曾经使用与本地相同的私钥
  • SSH_KNOWN_HOSTS
    • 我从本地计算机的 ~/.ssh/known_hosts 文件中获取了 gitlab.com 已知主机
    • <代码> gitlab.com,35.231.145.151 ECDSA-SHA2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBFSMqzJeV9rUzU4kWitGjeR4PWSa29SPqJ1fVkhtj3Hw9xjLVXVYrU9QlYWrOLXBpQ6KWjbjTDTdDkoohFzgbEY =
    • SSH_DEPLOY_PRIVATE_KEY - I used to same private key that I used locally
    • SSH_KNOWN_HOSTS
      • I took the gitlab.com known host from my local computer's ~/.ssh/known_hosts file
      • gitlab.com,35.231.145.151 ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBFSMqzJeV9rUzU4kWitGjeR4PWSa29SPqJ1fVkhtj3Hw9xjLVXVYrU9QlYWrOLXBpQ6KWjbjTDTdDkoohFzgbEY=

      然后我在 .gitlab-ci.yml 中设置 SSH:

      I then setup the SSH inside .gitlab-ci.yml:

      script:
        - apt-get install openssh-client -y
        - eval $(ssh-agent -s)
        - echo "$SSH_DEPLOY_PRIVATE_KEY" | tr -d '
      ' | ssh-add - > /dev/null
        - mkdir -p /.ssh && touch /.ssh/known_hosts
        - echo "$SSH_KNOWN_HOSTS" >> /.ssh/known_hosts
        - mkdir -p ~/.ssh
        - chmod 700 ~/.ssh
      

      这似乎工作正常,我收到以下消息:Identity added: (stdin) (runner@....)

      This seemed to work fine and I got the following message: Identity added: (stdin) (runner@....)

      然后我添加了相同的 git clone 命令与服务器通信,但失败并出现以下错误:

      I then added the same git clone command to communicate with the server, and it failed with the following error:

      Cloning into '......'...
      Host key verification failed.
      fatal: Could not read from remote repository.
      
      Please make sure you have the correct access rights
      and the repository exists.
      

      在本地测试仍然有效.我使用上面相同的命令在本地设置 SSH(除了我使用 pacman -S openssh 来安装).

      Testing locally still works. I used the same commands above to setup the SSH locally (except I used pacman -S openssh to install instead).

      我该如何解决这个问题?

      How do I fix this?

      编辑

      我知道我可以直接在 GitLab CI 中执行 ssh-keyscan ,理论上这应该可以解决问题,但据我所知,这很容易受到 man-in-the- 中间攻击.我正在尝试寻找更安全的解决方案.

      I'm aware that I can execute ssh-keyscan directly in the GitLab CI and this should in theory solve the problem, but from what I know, this is susceptible to man-in-the-middle attacks. I'm trying to find a more secure solution.

      编辑 2

      直接在 GitLab CI 中运行 ssh-keyscan 后,我收到相同的错误消息.

      After running ssh-keyscan directly in the GitLab CI, I get the same error message.

      详细输出是一样的:

      $ GIT_SSH_COMMAND="ssh -vvv" git clone git@gitlab.com:..../.....git deployed
      Cloning into 'deployed'...
      Host key verification failed.
      fatal: Could not read from remote repository.
      
      Please make sure you have the correct access rights
      and the repository exists.
      

      编辑 3

      似乎已连接到互联网.加上 apt-get install 否则将无法正常工作.

      Seems to be connected to the internet. Plus apt-get install wouldn't work otherwise.

      编辑 4

      我不明白为什么这是一项如此艰巨的任务.我关注了 这篇文章 并且做的一切都是正确的.似乎还有很多其他类似的问题,也没有任何答案.这只是我们无法控制的 GitLab CI 问题吗?

      I don't understand why this is such a difficult task. I followed this article and am doing everything correctly. There seems to be plenty of other similar questions, which also do not have any answers. Is this just an issue with GitLab CI that we have no control over?

      我现在也认为这与 SSH 服务器是另一个 GitLab 存储库这一事实有关.也许 GitLab CI 会阻止同一网络内的 SSH 连接.不知道为什么,但这是一种可能性.也不知道没有 SSH 怎么连接.

      I'm also now thinking that it has something to do with the fact that the SSH server is another GitLab repo. Maybe GitLab CI blocks SSH connections within the same network. Not sure why but it's a possibility. Also don't know how you'd connect without SSH.

      编辑 5

      详细输出显然无法使用 GIT_SSH_COMMAND,所以我尝试了没有 git 的 ssh 连接:

      The verbose output clearly was not working using GIT_SSH_COMMAND, so I tried an ssh connection without git:

      ssh -vvvv git@gitlab.com
      

      日志输出:

      OpenSSH_6.7p1 Debian-5+deb8u5, OpenSSL 1.0.1t  3 May 2016
      debug1: Reading configuration data /etc/ssh/ssh_config
      debug1: /etc/ssh/ssh_config line 19: Applying options for *
      Pseudo-terminal will not be allocated because stdin is not a terminal.
      debug2: ssh_connect: needpriv 0
      debug1: Connecting to gitlab.com [35.231.145.151] port 22.
      debug1: Connection established.
      debug1: permanently_set_uid: 0/0
      debug1: key_load_public: No such file or directory
      debug1: identity file /root/.ssh/id_rsa type -1
      debug1: key_load_public: No such file or directory
      debug1: identity file /root/.ssh/id_rsa-cert type -1
      debug1: key_load_public: No such file or directory
      debug1: identity file /root/.ssh/id_dsa type -1
      debug1: key_load_public: No such file or directory
      debug1: identity file /root/.ssh/id_dsa-cert type -1
      debug1: key_load_public: No such file or directory
      debug1: identity file /root/.ssh/id_ecdsa type -1
      debug1: key_load_public: No such file or directory
      debug1: identity file /root/.ssh/id_ecdsa-cert type -1
      debug1: key_load_public: No such file or directory
      debug1: identity file /root/.ssh/id_ed25519 type -1
      debug1: key_load_public: No such file or directory
      debug1: identity file /root/.ssh/id_ed25519-cert type -1
      debug1: Enabling compatibility mode for protocol 2.0
      debug1: Local version string SSH-2.0-OpenSSH_6.7p1 Debian-5+deb8u5
      debug1: Remote protocol version 2.0, remote software version OpenSSH_7.2p2 Ubuntu-4ubuntu2.8
      debug1: match: OpenSSH_7.2p2 Ubuntu-4ubuntu2.8 pat OpenSSH* compat 0x04000000
      debug2: fd 3 setting O_NONBLOCK
      debug3: load_hostkeys: loading entries for host "gitlab.com" from file "/root/.ssh/known_hosts"
      debug3: load_hostkeys: loaded 0 keys
      debug1: SSH2_MSG_KEXINIT sent
      debug1: SSH2_MSG_KEXINIT received
      debug2: kex_parse_kexinit: curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
      debug2: kex_parse_kexinit: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-ed25519-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-dss-cert-v00@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,ssh-rsa,ssh-dss
      debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
      debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
      debug2: kex_parse_kexinit: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1,hmac-md5-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
      debug2: kex_parse_kexinit: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1,hmac-md5-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
      debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
      debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
      debug2: kex_parse_kexinit: 
      debug2: kex_parse_kexinit: 
      debug2: kex_parse_kexinit: first_kex_follows 0 
      debug2: kex_parse_kexinit: reserved 0 
      debug2: kex_parse_kexinit: curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1
      debug2: kex_parse_kexinit: ssh-rsa,rsa-sha2-512,rsa-sha2-256,ecdsa-sha2-nistp256,ssh-ed25519
      debug2: kex_parse_kexinit: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
      debug2: kex_parse_kexinit: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
      debug2: kex_parse_kexinit: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
      debug2: kex_parse_kexinit: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
      debug2: kex_parse_kexinit: none,zlib@openssh.com
      debug2: kex_parse_kexinit: none,zlib@openssh.com
      debug2: kex_parse_kexinit: 
      debug2: kex_parse_kexinit: 
      debug2: kex_parse_kexinit: first_kex_follows 0 
      debug2: kex_parse_kexinit: reserved 0 
      debug2: mac_setup: setup umac-64-etm@openssh.com
      debug1: kex: server->client aes128-ctr umac-64-etm@openssh.com none
      debug2: mac_setup: setup umac-64-etm@openssh.com
      debug1: kex: client->server aes128-ctr umac-64-etm@openssh.com none
      debug1: sending SSH2_MSG_KEX_ECDH_INIT
      debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
      debug1: Server host key: ECDSA f1:d0:fb:46:73:7a:70:92:5a:ab:5d:ef:43:e2:1c:35
      debug3: load_hostkeys: loading entries for host "gitlab.com" from file "/root/.ssh/known_hosts"
      debug3: load_hostkeys: loaded 0 keys
      debug3: load_hostkeys: loading entries for host "35.231.145.151" from file "/root/.ssh/known_hosts"
      debug3: load_hostkeys: loaded 0 keys
      debug1: read_passphrase: can't open /dev/tty: No such device or address
      Host key verification failed.
      

      倒数第二行表明它正在尝试使用 /dev/tty 文件与终端通信.当然,这个脚本是在非交互式庄园中运行的,所以它失败了.它不应该使用我的密钥而不是从终端请求密码吗?

      The second-last line indicates that it's trying to communicate with the terminal using the /dev/tty file. Of course, this script is running in a non-interactive manor so it fails. Shouldn't it be using my key instead of requesting a passphrase from the terminal?

      推荐答案

      您可能需要尝试将模式设置为 644 而不是 700.验证 SSH 主机密钥 文档,也是 SSH 默认用于此文件的内容.SSH 的某些部分对此非常特别 - 我不确定 known_hosts 是否特别.

      You may need to try setting the mode to 644 rather than 700. 644 is what is suggested in the Verifying the SSH host keys documentation, and is also what SSH uses for this file by default. Some parts of SSH are very particular about this - I'm not sure if known_hosts is particular.

      文档还提到您应该将 SSH_KNOWN_HOSTS 变量的值设置为 ssh-keyscanentire 输出,因为有多个密钥.

      The docs also mention you should set the value of SSH_KNOWN_HOSTS variable to the entire output of ssh-keyscan since there are multiple keys.

      以下 .gitlab-ci.yml 在 GitLab.com 上为我工作.注意使用 ~/.ssh/ 而不是 /.ssh/.

      The following .gitlab-ci.yml worked for me on GitLab.com. Note the use of ~/.ssh/ rather than /.ssh/.

      image: ubuntu:latest
      
      test_job:
        script:
        - apt-get update
        - apt-get install openssh-client git-core -y
        - eval $(ssh-agent -s)
        - echo "$SSH_DEPLOY_PRIVATE_KEY" | tr -d '
      ' | ssh-add - > /dev/null
        - mkdir -p ~/.ssh && touch ~/.ssh/known_hosts
        - echo "$SSH_KNOWN_HOSTS" >> ~/.ssh/known_hosts
        - git clone git@gitlab.com:gitlab-org/gitlab-ce.git
      

      这篇关于GitLab CI 中的 SSH 主机密钥验证失败的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆