web-dev-qa-db-fra.com

La vérification de la clé de l'hôte SSH a échoué dans GitLab CI

Configuration locale

J'ai créé une clé SSH publique et privée via la commande ssh-keygen.

J'ai décidé de configurer la clé privée localement avant de la configurer sur le gitlab CI de mon référentiel.

J'ai configuré la clé publique sur le serveur (dans ce cas, un autre dépôt gitlab, mais cela pourrait changer à l'avenir et ne devrait pas affecter la question).

J'ai réussi à communiquer avec le serveur localement via la commande suivante (dans ce cas, j'utilise SSH via git, mais cela peut encore changer à l'avenir):

git clone [email protected]:...../......git

Configuration de GitLab CI

J'ai alors décidé de configurer la clé privée et la communication sur gitlab CI.

Dans mon référentiel, j'ai accédé aux paramètres -> Variables d'intégration continue ->, Et ajouté les variables d'environnement suivantes:

  • SSH_DEPLOY_PRIVATE_KEY - J'ai utilisé la même clé privée que j'ai utilisée localement
  • SSH_KNOWN_HOSTS
    • J'ai pris l'hôte gitlab.com Connu du fichier ~/.ssh/known_hosts De mon ordinateur local
    • gitlab.com,35.231.145.151 ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBFSMqzJeV9rUzU4kWitGjeR4PWSa29SPqJ1fVkhtj3Hw9xjLVXVYrU9QlYWrOLXBpQ6KWjbjTDTdDkoohFzgbEY=

J'ai ensuite installé le SSH dans .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

Cela semblait bien fonctionner et j'ai reçu le message suivant: Identity added: (stdin) (runner@....)

J'ai ensuite ajouté la même commande git clone Pour communiquer avec le serveur, et elle a échoué avec l'erreur suivante:

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.

Les tests locaux fonctionnent toujours. J'ai utilisé les mêmes commandes ci-dessus pour configurer le SSH localement (sauf que j'ai utilisé pacman -S openssh Pour installer à la place).

Comment puis-je réparer ça?

Modifier

Je suis conscient que je peux exécuter ssh-keyscan Directement dans le CI GitLab et cela devrait en théorie résoudre le problème, mais d'après ce que je sais, cela est sensible aux attaques de l'homme du milieu. J'essaie de trouver une solution plus sécurisée.

Modifier 2

Après avoir exécuté ssh-keyscan Directement dans le CI GitLab, j'obtiens le même message d'erreur.

La sortie détaillée est la même:

$ GIT_SSH_COMMAND="ssh -vvv" git clone [email protected]:..../.....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.

Modifier 3

Semble être connecté à Internet. De plus, apt-get install Ne fonctionnerait pas autrement.

Édition 4

Je ne comprends pas pourquoi c'est une tâche si difficile. J'ai suivi cet article et je fais tout correctement. Il semble y avoir beaucoup d'autres questions similaires, qui n'ont pas non plus de réponses. Est-ce juste un problème avec GitLab CI sur lequel nous n'avons aucun contrôle?

Je pense aussi maintenant que cela a quelque chose à voir avec le fait que le serveur SSH est un autre dépôt GitLab. Peut-être que GitLab CI bloque les connexions SSH au sein du même réseau. Je ne sais pas pourquoi mais c'est une possibilité. Je ne sais pas non plus comment vous vous connecteriez sans SSH.

Éditer 5

La sortie verbeuse ne fonctionnait clairement pas en utilisant GIT_SSH_COMMAND, J'ai donc essayé une connexion ssh sans git:

ssh -vvvv [email protected]

Sortie du journal:

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: [email protected],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: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],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,[email protected],[email protected],[email protected],arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected],[email protected],arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: kex_parse_kexinit: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1,[email protected],[email protected],[email protected],[email protected],hmac-md5,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1,[email protected],[email protected],[email protected],[email protected],hmac-md5,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,[email protected],zlib
debug2: kex_parse_kexinit: none,[email protected],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: [email protected],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: [email protected],aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected]
debug2: kex_parse_kexinit: [email protected],aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected]
debug2: kex_parse_kexinit: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: kex_parse_kexinit: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: kex_parse_kexinit: none,[email protected]
debug2: kex_parse_kexinit: none,[email protected]
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 [email protected]
debug1: kex: server->client aes128-ctr [email protected] none
debug2: mac_setup: setup [email protected]
debug1: kex: client->server aes128-ctr [email protected] 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.

L'avant-dernière ligne indique qu'elle essaie de communiquer avec le terminal à l'aide du fichier /dev/tty. Bien sûr, ce script s'exécute dans un manoir non interactif donc il échoue. Ne devrait-il pas utiliser ma clé au lieu de demander une phrase secrète au terminal?

7
David Callanan

Je ne recommanderais pas d'utiliser la même clé privée. À la fois pour des raisons de sécurité et parce que cela pourrait causer d'autres problèmes. Assurez-vous également que le authorized_keys Le fichier contient la clé publique du serveur auquel vous souhaitez accéder, sinon le tout ne fonctionnera pas. Je suppose que vous avez suivi un guide dans le sens de celui-ci ?

J'espère que cela fait quelque chose.

0
NightDice