Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Host key verification failed #66

Closed
acca301 opened this issue Jul 5, 2016 · 10 comments
Closed

Host key verification failed #66

acca301 opened this issue Jul 5, 2016 · 10 comments

Comments

@acca301
Copy link

acca301 commented Jul 5, 2016

I have just started learning Concourse CI from the tutorial https://github.com/starkandwayne/concourse-tutorial On Step 12 got into troubles with git-resource, the process fails on SSH host key verification.

This is the link to the original issue so Dr Williams would be in the loop.

@concourse-bot
Copy link
Collaborator

concourse-bot commented Jul 5, 2016

Hi there!

We use Pivotal Tracker to provide visibility into what our team is working on. A story for this issue has been automatically created.

The current status is as follows:

This comment, as well as the labels on the issue, will be automatically updated as the status in Tracker changes.

@vito
Copy link
Member

vito commented Jul 5, 2016

You need to configure a private_key to use SSH URIs.

@acca301
Copy link
Author

acca301 commented Jul 5, 2016

private_key does not help either.

Host key verification occurs way before the SSH client has a chance to present the key.

@vito
Copy link
Member

vito commented Jul 6, 2016

Git has terrible error messages. It'll say that when really the auth failed, the repo didn't exist, or the moon was half full. I would double check the formatting of your private key. It should look like:

resources:
- name: foo
  type: git
  source:
    uri: ...
    private_key: |
      ---BEGIN BLAH BLAH---
      .....
      ---END BLAH BLAH---

@acca301
Copy link
Author

acca301 commented Jul 6, 2016

My bad. | was they key.
I usually do chomping with |-, thus mine was:

  resources:
  - name: foo
    type: git
    source:
      uri: ...
      private_key: |-
        ---BEGIN BLAH BLAH---
        .....
        ---END BLAH BLAH---

that was the show stopper in this case.

@vito
Copy link
Member

vito commented Jul 6, 2016

Ah, I guess the trailing linebreak is important for private keys. Good to know.

@concourse-bot
Copy link
Collaborator

Hello again!

All stories related to this issue have been accepted, so I'm going to automatically close this issue.

At the time of writing, the following stories have been accepted:

If you feel there is still more to be done, or if you have any questions, leave a comment and we'll reopen if necessary!

@JohannesRudolph
Copy link
Contributor

I can second the observation made by @vito that adding a trailing linebreak (i.e. empty line after private key changes the pipeline definition from
private_key: |-
to
private_key: |

even when using a parameter for the key. However, I still get an error checking for my repository, same for public repositories hosted on github.

resource script '/opt/resource/check []' failed: exit status 128

stderr:
Cloning into '/tmp/git-resource-repo-cache'...
Host key verification failed.
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

Any idea what could be causing this? How can I debug what's going on? Does the worker miss an entry to trust github.com host key (http://stackoverflow.com/questions/13363553/git-error-host-key-verification-failed-when-connecting-to-remote-repository)?

@JohannesRudolph
Copy link
Contributor

JohannesRudolph commented Sep 10, 2016

Turns out one part of my issue was caused by a wrong MTU setting for garden (host supports 1450 mtu only). Had to fix this on the docker host via --mtu 1400 for the docker daemon and in the docker-compose file I use to run concourse using
command: "worker --garden-mtu 1400"
for the worker.

The second part was this: I was using private-key: instead of private_key:
In both cases, fly set-pipeline happily accepted my inputs, letting me down only when trying to check the resource. grrr.

@llazzaro
Copy link

llazzaro commented Feb 6, 2017

I got the same error but in my case was a dns error.
I fixed this issue adding --garden-dns-server to a local ip address on the worker parameters.
it seems that garden uses hostname -i, which in ubuntu linux is 127.0.0.1, since this will run inside a container no dns will work this way.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants