Permission denied (publickey) when trying to ssh to container

Feedback & Bug Reports
1

Hi,

suddenly circleci containers start refusing my ssh connections. I believe it start happening after I updated the GPG key but I have no clue how this could be connected.

I repeated all the steps from Debugging with SSH - CircleCI and everything seems to be fine:

$ ssh git@github.com
PTY allocation request failed on channel 0
Hi jandudulski! You've successfully authenticated, but GitHub does not provide shell access.
Connection to github.com closed.

The used for authentication to github is also offered while connecting to circle:

debug1: Offering public key: /home/jandudulski/.ssh/id_rsa RSA SHA256:XfGPsB5pqXKbzic4XlbioYCRCc/AMuBuMNZQmNMn50w agent
debug1: send_pubkey_test: no mutual signature algorithm

What else I can try?

2

If you re-added a GPG key, you might have to Unfollow the project on the UI and then Follow again in order to verify auth

3

GPG key is used only for signing commits, not for SSH auth. And I already tried to unfollow, sing out and remove OAuth token - nothing helped.

4

I am seeing identical behavior except I have not changed a gpg key. Is it possible circleci changed something regarding minimum key length or algo? I have a 2048 bit length SHA256-RSA key that has worked in the past. It still authenticates to GitHub without issue. It is only sshing to circleci jobs that give me the error:

debug1: send_pubkey_test: no mutual signature algorithm

A newly generated 4096 bit length SHA256/RSA key still did not work.

A newly generated SHA256/ED25519 key did work.

5

+1 on this issue, myself and some coworkers experiencing this seemingly out of no where.

Have confirmed that SSH keys work for github following debug steps linked above. Everything “seems fine” alas nothing.

Even tried adding new keys and everything,.

6

Hello

I suspect the situation you’re facing is related to changes Github implemented with regards to SSH keys

Depending on the key type, signature algorithms, or algorithms, and also, depending on when the key was created you might see different outcomes.

Let me know if the above information helps.

7

I ran into this today after updating to Pop OS 22.04. More relevant I think is that my OpenSSH version was also updated (8.9).

I was seeing the same issue as @brandonw eg.

debug1: send_pubkey_test: no mutual signature algorithm

I followed the CircleCI debugging post as well as read through the Github blog post.

@brandonw 's fix worked for me, eg. generate a new SHA256/ED25519 key (ssh-keygen -t ed25519) and upload that key to my Github account.

A co-worker of mine pointed out that there were some breaking changes as of OpenSSH 8.8 that may affect signatures used. From https://www.openssh.com/txt/release-8.8:

This release disables RSA signatures using the SHA-1 hash algorithm
by default. This change has been made as the SHA-1 hash algorithm is
cryptographically broken, and it is possible to create chosen-prefix
hash collisions for <USD$50K [1]

Incompatibility is more likely when connecting to older SSH
implementations that have not been upgraded or have not closely tracked
improvements in the SSH protocol. For these cases, it may be necessary
to selectively re-enable RSA/SHA1 to allow connection and/or user
authentication via the HostkeyAlgorithms and PubkeyAcceptedAlgorithms
options.

Indeed if I add the suggested changes to ~/.ssh/config, I can get past the error above with my old keys:

Host old-host
        HostkeyAlgorithms +ssh-rsa
	PubkeyAcceptedAlgorithms +ssh-rsa

This would imply that CircleCI is using an old SSH agent and needs to update for compatibility with newer client agents. Or CircleCI needs to inform users to update to a SHA256/ED25519 key.

4 Likes
8

I am running into the same issue as everyone else, and seeing the “no mutual signature algorithm” error as posted above.

@m4olivei 's solution of creating a .ssh/config file resolved the issue for me.

1 Like
9

I needed to do this after an upgrade to Ventura on Mac OSX. SSH config solution works if I put the host name for the SSH session as the Host directive