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

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

问题描述

本地设置

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

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

我决定先在本地设置私钥,然后再在我的仓库的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 '\r' | 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).

      我该如何解决?

      修改

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

      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.

      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-keyscan entire 输出,因为有多个键.

      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 '\r' | 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
      

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

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