Known Hosts in Circle 2.0?


#1

Hey, all. I’m trying to get my build converted to Circle 2.0, and I’m slightly stumped by a seemingly small problem. I use the last step of my deploy process to create and push a new tag for each build - and pushing the tag back to github is failing with the following errors:

:tagInternalVersionHost key verification failed.

fatal: Could not read from remote repository.

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

From what I can tell, this seems to indicate that the “git push --tags” command is failing because the job can’t connect to github correctly. And sure enough, when I ssh into my build and manually run “git push --tags”, I get the following:

Host key verification failed.
fatal: Could not read from remote repository.

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

From what I can tell, this likely indicates that github isn’t added to known_hosts/ssh config correctly. But the strange part is that this is all working just fine for the same project on Circle 1.0 - so I know that I have my deploy key created and set up correctly with both Circle and Github.

Here’s my config for the relevant job. I added the add_ssh_keys step, and I see this take effect - but it doesn’t seem sufficient to fix the problem. I’m sure this is something incredibly stupid on my part, but I can’t seem to find documentation of the right fix here.

  deploy:
    docker:
      - image: circleci/android:api-27-alpha
    steps:
      # Attach the previously used workspace.
      - *attach_workspace
      - restore_cache:
        keys:
          - *android_cache_key
          - *ruby_cache_key
      - add_ssh_keys
      - run:
          name: Install Fastlane
          command: gem install fastlane
      - save_cache:
          paths:
            - "/opt/circleci/.rvm/gems"
          key: *ruby_cache_key
      - deploy:
          command: fastlane deploy_tot

Any advice would be very much appreciated!


Known_hosts edit fails using local CLI
#2

For reference, it looks like this can be solved by adding the following to my config:

- add_ssh_keys
- run:
    name: Keyscan Github (HACK)
    command: ssh-keyscan -H github.com >> ~/.ssh/known_hosts

It doesn’t seem like this should be necessary, given the docs, but it appears to work from what I’m seeing now.


#3

Out of curiosity, if you run checkout in this job, does it work then? It’s possible that checkout adds the default Github SSH checkout key and add_ssh_keys does not.


#4

In my workflows, I avoid ssh authentication problems by restoring the state of ~/.ssh after a checkout step in later jobs:

  cache_key_ssh: &cache_key_ssh
    v1.00-monorail.ssh.rev-{{ .Revision }}

  restore_ssh: &restore_ssh
    restore_cache:
      keys:
        - *cache_key_ssh

jobs:
  get_code:
    steps:
      [...]
      - checkout
      - save_cache:
          key: *cache_key_ssh
          paths:
            - ~/.ssh

  build:
    steps:
      - *restore_code
      - *restore_ssh

You could have a similar outcome by passing switches to ssh to skip host key verification. Your workaround of using ssh-keygen is filling out ~/.ssh/known_hosts, and my version does the same by copying the entire ~/.ssh directory.

CircleCI’s pattern does “fill out known_hosts correctly”, but the files you create during earlier workflow steps are not available during later steps, unless you arrange to put them there (via cache or workspace operations). This is the particular behavior that’s different from CircleCI v1.0 configurations.

Eric’s explanation that add_to_ssh might not be preserving known_hosts may very well be true as well. That’s not surprising because just adding ssh keys to an ssh agent doesn’t manipulate any files in ~/.ssh while the the checkout operations definitely do.


#5

This topic was automatically closed 41 days after the last reply. New replies are no longer allowed.