SSH can't establish authenticity of host, despite adding options, keys, known_hosts, etc

I’m new to CircleCI and I’m having an issue that others have had before, but won’t resolve for me no matter what I try.

At the last step, where rsync invokes ssh I get

The authenticity of host ' (' can't be established
ECDSA key fingerprint is SHA256:xxxxx. Are you sure you want to continue connecting (yes/no)?

I’ve tried:

  • Recreating a new key with no passphrase on the host server, and adding that to CircleCI’s project settings
  • Writing PubkeyAuthentication yes and StrictHostKeyChecking no to the client’s (Docker instance) ~/.ssh/config
  • Using add_ssh_keys and adding the corresponding fingerprint (as shown in the CircleCI UI, under SSH keys in project settings)
  • Adding to known_hosts on the client instance, both using ssh-keyscan and by directly writing the host + signature as it appears on my local machine’s known_hosts
  • Trying to add options directly to my rsync/ssh command: -o BatchMode=yes, -o StrictHostKeyChecking=no, -o UserKnownHostsFile=/dev/null
  • Tried rsync with and without sudo

All of these solutions seem to have solved the issue for others (1), (2) but not in my case. Any ideas?

  • My config is below, exactly as it appears in my repo (some things I tried earlier are commented out)
  • I edited the IP addresses and signatures for the purpose of this post

Here’s my .circleci/config.yml

version: 2
    working_directory: ~/frontend
      - image: circleci/node:11.11.0-stretch-browsers
      - type: shell
        shell: /bin/sh
        pwd: /
        command: sudo apt update && sudo apt install git -y && git --version

      # Update environment
      - run: sudo apt update
      - run: sudo apt-get install rsync

      # Sync the SSH keys
      # - run:
          # name: skip key authentication message
          # command: |
          #   sudo cat ~/.ssh/config
          #   sudo chmod 400 ~/.ssh/config            
          #   echo "PubkeyAuthentication yes" >> ~/.ssh/config
          #   echo "StrictHostKeyChecking no" >> ~/.ssh/config
          #   service sshd restart

      - add_ssh_keys:
            - "88:1a:2b:3c:4d:5f:1a:2b:3c:4d:5f"

      # Check out the code in the project directory
      - checkout

      # Install JS dependencies
      # - run: yarn install --no-progress --non-interactive --silent --pure-lockfile
      - run: npm ci
      - run: sudo npm install nuxt -g --loglevel=error

      # Run build command
      - run: sudo nuxt build

      # Add the server to known hosts
      - run:
          name: add to known hosts
          command: |
            sudo ssh-keyscan -H >> ~/.ssh/known_hosts
            sudo echo " ecdsa-sha2-nistp256 AAABBBL09....AAAAQ=" >> ~/.ssh/known_hosts

      # Upload files to server.
      - run: sudo rsync -avce ssh --delete ./dist/ -o BatchMode=yes -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null production@

Hi @orvn,

Welcome to our community forum!

Could you please SSH into a container and run the commands manually and see if you are still getting the error.

Also, once try to directly do the SSH with verbose mode from the container and see if you can ssh to your host server.

Pawan Bahuguna

1 Like

Thanks for that @Pawan, very helpful. I didn’t know you could SSH into the container while it was running.

Once I got in, I saw that a simple ssh production@ from within the container actually worked fine. So my issue was not the ssh, but rsync.

I wanted to keep rsync because in my experience it’s a lot more reliable than other solutions like scp. To solve it I:

  1. Removed the sudo from the rsync command (because it doesn’t just run rsync as sudo on the client, but also tries to on the host/destination machine)
  2. Removed all the superfluous options, which are fine when using bin/ssh, but are not accepted when invoking ssh over rsync.

So for me, changing the final command to the one below fixed the issue.
rsync -cave ssh production@

1 Like

Great news! Thanks for updating.

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