"Invalid key length" when trying to ssh to container

ssh

#1

I’m trying to migrate a project to circle 2.0, and am unable to SSH to containers I’ve triggered “with SSH”. Specifically:

ssh -a -i .ssh/id_rsa -p 64535 54.236.44.152
ssh_dispatch_run_fatal: Connection to 54.236.44.152 port 64535: Invalid key length

I normally use an ssh agent to connect, but can reproduce this by creating a dedicated SSH RSA key, adding it to github and disabling the agent. The image is circleci/golang:1.9-stretch

This functionality worked just fine on Circle 1.0 (with the SSH agent), so what’s going wrong?


#2

Hi,

To start ruling out some issues, have you followed the troubleshooting steps in our doc?


#3

I have - connecting to github.com works fine, so the key is ok. A more verbose output is:

$ ssh -a -i .ssh/id_rsa -v -p 64535 54.85.136.112
OpenSSH_7.6p1, OpenSSL 1.1.0f  25 May 2017
debug1: Reading configuration data /home/growse/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Connecting to 54.85.136.112 [54.85.136.112] port 64535.
debug1: Connection established.
debug1: identity file .ssh/id_rsa type 0
debug1: key_load_public: No such file or directory
debug1: identity file .ssh/id_rsa-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_7.6
debug1: Remote protocol version 2.0, remote software version Go
debug1: no match: Go
debug1: Authenticating to 54.85.136.112:64535 as 'growse'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256@libssh.org
debug1: kex: host key algorithm: ssh-rsa
debug1: kex: server->client cipher: aes128-ctr MAC: hmac-sha2-256-etm@openssh.com compression: none
debug1: kex: client->server cipher: aes128-ctr MAC: hmac-sha2-256-etm@openssh.com compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
ssh_dispatch_run_fatal: Connection to 54.85.136.112 port 64535: Invalid key length

#4

So the problem is the cipher types are matching up between your SSH client and the server. I’m trying to figure out to best way to solve this.

What OS did you create your key on? Do you happen to know the SSH client and version? Most people use OpenSSH.

So far I’ve seen around the web some users get around this issue by adding Ciphers aes128-ctr,aes192-ctr,aes256-ctr to their ~/.ssh/config but I’m stilling researching.


#5

Both the keys for my agent and the new temporary RSA key I used to test were created on Arch Linux, which currently is using openssh 7.6p1-1.


#6

debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
ssh_dispatch_run_fatal: Connection to 54.85.136.112 port 64535: Invalid key length

I’m experiencing this problem as well on CircleCI 2.0. I’ve tried ciphers aes128-ctr, ,aes192-ctr, and aes256-ctr using ssh -c

I was able to SSH using the same keys in CircleCI 1.0 and a few weeks ago CircleCI 2.0 was also working.


#7

I get the same error on new laptop but not on old. Have same keys.
I feel like some settings are different and how -p is handled?

I can ssh into git and different instances as before using private key but not into circleci.


#8

https://www.openssh.com/releasenotes.html

7.6:
Refuse RSA keys <1024 bits in length and improve reporting for keys
that do not meet this requirement.

I guess their ssh utility is crap.


#9

Works for me with default macOS ssh, but not with Homebrew’s openssh.


#10

So it sounds like the sshd circle use needs to generate a longer host key length. Is there a way to find out what the key length currently is to verify that this is likely the problem?


#11

+1 here. I’m also using Arch, which has a rolling release system so would be expected to get new versions of things fairly quickly. I have openssh 7.6p1.

At the moment to ssh onto my builds I have to make a container with an older openssh version and copy my key into it. I expect this problem will become more widespread as people move onto openssh 7.6 (it’s only about 3 weeks old).


#12

I think the issue will not be fixed by changing the Ciphers or any other configs for that matter, I followed this superuser thread for fixing this and only ishitatsuyuki’s reply makes sense. So I think changing the ssh config on the docker images will be enough to allow ssh logins.

the logs obtained via ssh -v says the same as it uses 128 bit key the client side is rejecting it (I’m no security expert here, feel free to correct me if I’m wrong).

debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256@libssh.org
debug1: kex: host key algorithm: ssh-rsa
debug1: kex: server->client cipher: aes128-ctr MAC: hmac-sha2-256-etm@openssh.com compression: none
debug1: kex: client->server cipher: aes128-ctr MAC: hmac-sha2-256-etm@openssh.com compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
ssh_dispatch_run_fatal: Connection to <redacted> port <redacted>: Invalid key length

I think trying the same by creating a sample container with custom docker image changing the generated ssh key (I have no idea how), might fix this issue.


#13

+1

@FelicianoTech Any update on this issue?


#14

Same issue here, Arch as well.


#15

Any progress on this?

OpenSSH_7.6p1, OpenSSL 1.1.0f 25 May 2017


#16
═╡$│ssh -V           
OpenSSH_7.6p1, OpenSSL 1.1.0g  2 Nov 2017
═╡$│openssl          
OpenSSL> version
OpenSSL 1.1.0g  2 Nov 2017

same issue for me here


#17

As another clue, this worked a few days ago until I upgraded to the latest SSH version (OpenSSH_7.6p1, OpenSSL 1.0.2k 26 Jan 2017). Now I’m getting the same error.


#18

The public beta of macOS High Sierra 10.13.2 has OpenSSH_7.6p1 so this is going to become more and more of a problem.


#19

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


#20

Hi all,

Reopening this thread because I’m investigating this issue for another customer—is this something y’all are still running into?

I’m curious, because I’m on High Sierra 10.13.2 and running OpenSSH_7.6p1 and I can’t reproduce the error on my end…