Discussion and resolution for "ERROR: You're using an RSA key with SHA-1, which is no longer allowed"

Build Environment
1

The brownout has ended, and builds that were previously failing over the last 24 hours should execute normally as they had prior to the brownout

Hi All,

We have seen an increase in topics and tickets related to the following error:

ERROR: You're using an RSA key with SHA-1, which is no longer allowed

That is happening with the - checkout step. This is related to some changes on GitHub’s end, a bit more details here:

With the above in mind, the path forward is to get on a newer version of openSSH, this can be done by upgrading to a newer image version or installing openSSH directly before your - checkout step.

Upgrade image example

If you are on the machine executor, you can upgrade to a newer version by specifying an image in your config, so you would update:

jobs:
  jobname:
    machine: true
...

To something like the following:

jobs:
  jobname:
    machine:
      image: ubuntu-2004:202010-01
...

We have a list of machine images available here, most of the newer ones should work.

If you are using the docker executor, you’ll need to find a newer version of the docker image you are using that has the proper openSSH items installed. Usually, the most recent image should suffice.

Manual install new openSSH version example

If you are unable to update your image and instead want to install openSSH manually, this can be done in a - run step before you call - checkout . This will do that on Linux based images:

jobs:
  jobname:
    machine: true
    steps:
      - run:
          name: Install OpenSSH 8.1p1
          command: |
            sudo apt-get update
            mkdir ~/tempdownload; cd ~/tempdownload; wget https://cdn.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-8.1p1.tar.gz; tar zxvf openssh-8.1p1.tar.gz; cd openssh-8.1p1 && ./configure && make && sudo make install
      - checkout
...

If the image you are using isn’t Linux-based, you’ll need to investigate what options are available for your operating system to install the newer version.

EDIT: One other item discovered in the discussion of this thread is there are situations where openSSH may be on the proper version (7.2+) but git isn’t installed on the docker image you are utilizing. You can install it, as an example like this:

- run:
      name: Install git for checkout
      command: |
          apt-get update && apt-get --no-install-recommends -y install git

If you are using an Orb job you can utilize a pre-step to have it execute before any other code in that job as well. More information on pre-steps here.

We have done some testing and the above two options should allow for the - checkout step to work again without modifying any keys. If you encounter any further issues please let us know!

-Nick

2

@nbialostosky How does update this for an orb? I’m trying to update my (only) orb and the test-pack job is failing in the shellcheck/check step due to this error.

I tried updating the shellcheck orb from:

circleci/shellcheck@2.0

to the latest version I saw in the registry:

circleci/shellcheck@2.2.4

but that didn’t seem to help.

3

@mathomp4 Looks like that orb utilizes this docker image:

https://hub.docker.com/r/koalaman/shellcheck-alpine/tags

I checked the latest tag on the above in a test and it doesn’t have the proper items installed to get this to work. I went ahead and opened an issue for this:

However, in the meantime, you should be able to swap to using the commands associated with the Orb (instead of the Job):

And if needed, install the newer version of openSSH before executing the commands:

      - run:
          name: Install OpenSSH 8.1p1
          command: |
            sudo apt-get update
            mkdir ~/tempdownload; cd ~/tempdownload; wget https://cdn.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-8.1p1.tar.gz; tar zxvf openssh-8.1p1.tar.gz; cd openssh-8.1p1 && ./configure && make && sudo make install

Hope that helps!

4

Thanks for opening this issue. For now I might just comment out that step. I mean, I don’t really have any shell code to check in my orb, so maybe I can “avoid” it.

But I’ll subscribe to that issue and then I can re-enable it in my orb when I might have some shell code to check. :slight_smile:

1 Like
5

Will CircleCI be doing anything to address this issue, or should we plan to start mass-fixing all our workflows?

My team is seeing this problem on images that don’t have git installed (and where CircleCI is apparently somehow checking out the code on our behalf).

6

My container-based jobs are currently failing with the following:

Either git or ssh (required by git to clone through SSH) is not installed in the image. Falling back to CircleCI's native git client but the behavior may be different from official git. If this is an issue, please use an image that has official git and ssh installed.
Cloning git repository

error cloning repository: unknown error: ERROR: You're using an RSA key with SHA-1, which is no longer allowed. Please use a newer client or a different key type.

I use an Amazon Linux 2 container, which does not contain any git or ssh tools by default. OpenSSH 7.4, with support for the safer hash algorithms, is available in the yum repositories, but it seems like the problem here is related to “CircleCI’s native git client” and that the failure happens before I even have an opportunity to install additional software.

I have confirmed that Amazon Linux 2 can clone from GitHub.

Do I need to construct a custom container image with git and ssh pre-installed? Given that I didn’t need to do that previously, this seems like a regressions.

7

Thanks for the replies here – seems like both questions are related to git and utilizing the - checkout step. I am getting this investigated on our end to see what may need to be changed, or what the best path forward is.

In the meantime other customers who ran into the error y’all are seeing where openSSH is on a version GitHub supports simply installing git on the image seems to do the trick, example of that install:

- run:
      name: Install git for checkout
      command: |
          apt-get update && apt-get --no-install-recommends -y install git

This would just need to be placed before the - checkout step in a job, or added as a pre-step if you are using an orb job and it should allow your builds to continue.

If the above doesn’t work, can you provide a sanitized version of your config file with the relevant job having issues? Alternatively, if you don’t want to share publically you can submit a ticket and we can take a look there.

Thanks!

8

just ran the above Install git for checkout command but did not work for me. :frowning_face:

#!/bin/bash -eo pipefail
apt-get update && apt-get --no-install-recommends -y install git

Get:1 http://archive.ubuntu.com/ubuntu focal InRelease [265 kB]
Get:2 http://security.ubuntu.com/ubuntu focal-security InRelease [114 kB]
Get:3 http://archive.ubuntu.com/ubuntu focal-updates InRelease [114 kB]
Get:4 http://security.ubuntu.com/ubuntu focal-security/multiverse amd64 Packages [30.1 kB]
Get:5 http://archive.ubuntu.com/ubuntu focal-backports InRelease [108 kB]
Get:6 http://security.ubuntu.com/ubuntu focal-security/restricted amd64 Packages [825 kB]
Get:7 http://archive.ubuntu.com/ubuntu focal/multiverse amd64 Packages [177 kB]
Get:8 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages [1275 kB]
Get:9 http://security.ubuntu.com/ubuntu focal-security/universe amd64 Packages [837 kB]
Get:10 http://archive.ubuntu.com/ubuntu focal/universe amd64 Packages [11.3 MB]
Get:11 http://security.ubuntu.com/ubuntu focal-security/main amd64 Packages [1410 kB]
Get:12 http://archive.ubuntu.com/ubuntu focal/restricted amd64 Packages [33.4 kB]
Get:13 http://archive.ubuntu.com/ubuntu focal-updates/universe amd64 Packages [1118 kB]
Get:14 http://archive.ubuntu.com/ubuntu focal-updates/multiverse amd64 Packages [33.7 kB]
Get:15 http://archive.ubuntu.com/ubuntu focal-updates/restricted amd64 Packages [899 kB]
Get:16 http://archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages [1844 kB]
Get:17 http://archive.ubuntu.com/ubuntu focal-backports/main amd64 Packages [50.8 kB]
Get:18 http://archive.ubuntu.com/ubuntu focal-backports/universe amd64 Packages [22.4 kB]
Fetched 20.5 MB in 2s (9187 kB/s)                       
Reading package lists... Done
Reading package lists... Done
Building dependency tree       
Reading state information... Done
git is already the newest version (1:2.25.1-1ubuntu3.2).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
CircleCI received exit code 0

but

Either git or ssh (required by git to clone through SSH) is not installed in the image. Falling back to CircleCI's native git client but the behavior may be different from official git. If this is an issue, please use an image that has official git and ssh installed.
Cloning git repository

error cloning repository: unknown error: ERROR: You're using an RSA key with SHA-1, which is no longer allowed. Please use a newer client or a different key type.
9

Funny, because I am a new user of CircleCI and just started integrating it into one of my GitHub projects and ran into this. My job will not run the checkout step. Here’s my simple config.

I also attempted the Install git for checkout command and received the following error.

E: Could not open lock file /var/lib/apt/lists/lock - open (13: Permission denied)
E: Unable to lock directory /var/lib/apt/lists/
E: Could not open lock file /var/lib/dpkg/lock - open (13: Permission denied)
E: Unable to lock the administration directory (/var/lib/dpkg/), are you root?

Exited with code exit status 100

EDIT: Looks like I replied too soon and did not read the original post thoroughly enough. Upgrading to a newer linux machine fixed this for me.

1 Like
10

@nbialostosky Thanks for your quick reply! The order was the key detail here. I needed to move the dependency installation step to happen before the checkout step. Once that was done, things worked fine.

1 Like
11

Hi @peter0083 – can you confirm the executor you are using (machine or docker) and what image you are utilizing? If the git install step didn’t do the trick, the openSSH version could be out of date still. You can check that with a run step:

- run: ssh -V
1 Like
12

For my case I had a docker executor

jobs:
  build:
    working_directory: /app
    docker:
      - image: docker:20.10.12
    steps:
      - checkout
      - setup_remote_docker

It did work after installing git in Alpine Linux like this

jobs:
  build:
    working_directory: /app
    docker:
      - image: docker:20.10.12
    steps:
      - run:
          name: Install Git Client
          command: apk add git

      - checkout
      - setup_remote_docker
2 Likes
13

@nbialostosky thank you for keeping us up-to-date, and looking for solutions.

I hope y’all keep in mind that for some organizations with hundreds of projects in CircleCI, this problem is extremely disruptive. This current problem is still an outage for some of your customers.

We are getting this error below (as already shown elsewhere) because we are running images where git and ssh aren’t installed.

CircleCI’s “native git client” is actually a helpful feature of yours that we’re taking advantage of (for better or worse). It’s a helpful feature for certain off-the-shelf docker images we happen to require.

Please let us know whether we should expect a solution from you, because patching hundreds of projects is bad but having all your deployments broken for a day is worse.

Either git or ssh (required by git to clone through SSH) is not installed in the image. Falling back to CircleCI’s native git client but the behavior may be different from official git. If this is an issue, please use an image that has official git and ssh installed.
Cloning git repository

error cloning repository: unknown error: ERROR: You’re using an RSA key with SHA-1, which is no longer allowed. Please use a newer client or a different key type.

2 Likes
14

Thanks for the reply.

I got mine working

 steps:
      - run: # to address issue of RSA key with SHA-1 which is no longer allowed
          name: Install OpenSSH
          command: |
            apt update -y && apt install -y openssh-client
      - checkout

It turned that I was not able to run make to build the package in my container using

mkdir ~/tempdownload; cd ~/tempdownload; wget https://cdn.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-8.1p1.tar.gz; tar zxvf openssh-8.1p1.tar.gz; cd openssh-8.1p1 && ./configure && make && sudo make install

but your suggestion of fixing openSSH was still the right idea.

running

apt update -y && apt install -y openssh-client

before checkout worked!

1 Like
15

Hi All,

We have confirmed that the brownout scheduled for January 11, 2022 has completed. Builds that were previously failing over the last 24 hours should execute normally as they had prior to the brownout.
We are investing solutions to the build failures so that this does not happen when the changes are made permanent on March 15, 2022.

For any outstanding issues or questions regarding this, please feel free to post on our forum or submit a support ticket.

Thank you.

2 Likes
16

Hi All –

I wanted to send a follow-up message here to confirm the path forward and what actions we are taking before the March 15th cutoff.

We have already taken action in regards to the deploy and user keys generated for projects, all newly generated keys will be ed25519 and meet the requirements being set forth by GitHub. This means that if you generate a new key for your projects you won’t need to take any other actions, such as the workarounds we provided in this thread.

Beyond the above, we are investigating our options internally on how to handle the existing keys associated with projects which will no longer be valid come March 15th. Ideally, we will be able to take action on our end so the cutover is seamless for all customers even if they don’t manually regenerate the keys in the meantime. CC @aaron.evans – this would ideally solve your use case given the number of projects you have.

If you have any additional questions in the meantime please let me know! Otherwise, we will continue to communicate via Discuss on any actions we take in regards to this GitHub deprecation.

-Nick

17

Hi All!

Thanks for your patience as we worked on the details for this situation on our end, we have posted an in-depth guide on taking care of this situation before March 15th arrives, you can find it here:

In addition to the above, if you have a lot of projects you need to regenerate keys for you’ll find a helpful script to assist with that here:

1 Like
18

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