4

I'm trying to use gitlab CI/CD to auto deploy my code, after push on an specific branch (in my case 'staging' branch)

after push on 'staging' branch I see following error on jobs section in gitlab UI:

Running with gitlab-runner 15.0.0 (xxxxxx)
  on deploy xxxxxx
Preparing the "ssh" executor
00:36
Using SSH executor...
ERROR: Preparation failed: ssh command Connect() error: ssh Dial() error: ssh: handshake failed: knownhosts: key is unknown

I can see gitlab from my VM and gitlab-runner registered successfully before.

I've also created ssh key and add it to gitlab-runner installation steps.

torek
  • 448,244
  • 59
  • 642
  • 775
shahab valizade
  • 98
  • 1
  • 8
  • The `Dial()` part suggests that this is using Go's ssh implementation. The "known hosts" stuff is, well, what [VonC said](https://stackoverflow.com/a/72593914/1256452). Command-line ssh can be told "trust on first use" and that's actually the usual default, so if you're connect to `gitlab.com` for the *first time*, ssh will read the data coming from whoever answers at `gitlab.com` and save it in your `.ssh/known_hosts` file. *Without* "trust on first use", though, you must preload the correct host key. – torek Jun 12 '22 at 20:34
  • For the usual Go ssh `Dial()` function, however, the host key is handled by a `HostKeyCallback` function (see [the `ClientConfig` documentation](https://pkg.go.dev/golang.org/x/crypto/ssh#ClientConfig) and [the `HostKeyCallback` documentation](https://pkg.go.dev/golang.org/x/crypto/ssh#HostKeyCallback)). What gitlab-ci-runner uses, I have no idea. – torek Jun 12 '22 at 20:37

2 Answers2

3

You need to check what SSH URL is used in your case.

Something like git@gitlab.com:me/myProject would look for gitlab.com SSH host keys fingerprints in an ~/.ssh/known_hosts file.

Make sure to add first in gitlab-runner server the following to ~/.ssh/known_hosts:

gitlab.com ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIAfuCHKVTjquxvt6CM6tdG4SLp1Btn/nOeHHE5UOzRdf
gitlab.com ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCsj2bNKTBSpIYDEGk9KxsGh3mySTRgMtXL583qmBpzeQ+jqCMRgBqB98u3z++J1sKlXHWfM9dyhSevkMwSbhoR8XIq/U0tCNyokEi/ueaBMCvbcTHhO7FcwzY92WK4Yt0aGROY5qX2UKSeOvuP4D6TPqKF1onrSzH9bx9XUf2lEdWT/ia1NEKjunUqu1xOB/StKDHMoX4/OKyIzuS0q/T1zOATthvasJFoPrAjkohTyaDUz2LN5JoH839hViyEG82yB+MjcFV5MU3N1l1QL3cVUCh93xSaua1N85qivl+siMkPGbO5xR/En4iEY6K2XPASUEMaieWVNTRCtJ4S8H+9
gitlab.com ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBFSMqzJeV9rUzU4kWitGjeR4PWSa29SPqJ1fVkhtj3Hw9xjLVXVYrU9QlYWrOLXBpQ6KWjbjTDTdDkoohFzgbEY=

That will skip manual fingerprint confirmation in SSH.
In other words, no more "knownhosts: key is unknown".

Note that with GitLab 15.3 (August 2022), you will have an easier time finding those:

New links to SSH fingerprints

Your GitLab SSH fingerprints are now easier to find, thanks to new links on the SSH configuration page and in the documentation.

Thank you Andreas Deicha for your contribution!

https://about.gitlab.com/images/15_3/manage-ssh-fingerprint.png -- New links to SSH fingerprints

See Documentation and Issue.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • thank you for your help. I'm using a completely different gitlab (for example gitlab.company.com) server for the company. can you help me, how can I get ssh host keys fingerprints for this private gitlab server? – shahab valizade Jun 17 '22 at 07:28
  • 1
    @shahabvalizade Usually, the first ssh git@gitlab.company.com will prompt you to accept the key fingerprint, and update the `~/.ssh/known_hosts` automatically. But you have to ask an admin to confirm those are the correct ones. – VonC Jun 17 '22 at 07:44
  • I'm Stack. This is not working for me. I don't know why. – Hasibur Rahman Jun 25 '22 at 18:57
  • @HasiburRahman Then it is best to describe your issue in a separate question. – VonC Jun 25 '22 at 20:06
  • I am also getting same error. Can you pls provide a solution Error: "ERROR: Preparation failed: ssh command Connect() error: ssh Dial() error: ssh: handshake failed: knownhosts: key is unknown" @VonC – Anirban Das Oct 12 '22 at 13:54
  • @AnirbanDas At first glance, the solution seems to be the same as the one written above. Please ask a separate question if it is not enough. – VonC Oct 12 '22 at 14:27
0

For people who still encounter this issue: in our case the cause was a difference between the host name in the known_host file and the one in the toml file. They must be both fully qualified or both non qualified.

Marcus
  • 1
  • Your answer could be improved with additional supporting information. Please [edit] to add further details, such as citations or documentation, so that others can confirm that your answer is correct. You can find more information on how to write good answers [in the help center](/help/how-to-answer). – Community Oct 25 '22 at 01:43