[BUG] StrictHostKeyChecking=accept-new causes install failure on OpenSSH <7.6

[luxaritas]

As seen in the comments on npm/cli#3233 and #7, trying to install a git repository with the current npm CLI fails when using OpenSSH <7.6 with the following:

npm ERR! command git --no-replace-objects ls-remote ssh://git@gitserver.com/foo/bar.git
npm ERR! command-line line 0: unsupported option "accept-new".
npm ERR! fatal: Could not read from remote repository.

While the change is in theory a good one (I was caught off guard with the old behavior when cloning a repository failed due to a missing host key), it creates issues in practice.

• OpenSSH >= 7.6 probably can't be expected - at the very least in my case, on an up-to-date Amazon Linux, I'm stuck with 7.4p1 from the repositories, and I'd rather not compile from source.
• This implementation overrides .git/config and ~/.gitconfig, contrary to the PR (and ~/.ssh/config as well, as someone pointed out)

Proposals I've seen include:

• Verifying the current ssh version (ssh -V) before attempting to use accept-new
• Wholesale reversion of #7

[darcyclarke]

@nlf if you're looking at this repo &/or changing anything can you review this issue

[nlf]

😞 i was operating under the assumption that a nearly 4 year old release of openssh was going to be a low enough bar that this would be reasonable, but it appears not if Amazon Linux doesn't have it. we'll revisit this and try to come up with another way. thanks for the report!

[adamlounds]

One workaround for anyone else finding this: specify the GIT_SSH_COMMAND env var when calling npm, eg GIT_SSH_COMMAND="ssh" npm install

[joshuawinsor]

Even if this didn't error, it is still problematic as it downgrades ssh security by default.

[kumarrishav]

I am facing the same issue as well. What's the solution for this other than updating openssh version or using workaround?

[pkyeck]

we'll revisit this and try to come up with another way.

@nlf did you come up with something?

[lacksfish]

This is a breaking change imho and should be communicated as such. Some of my Dockerfiles stopped working due to this code change.

What if no newer version of OpenSSH is available ? Will there be a working fallback ?

[Mayank16799]

@joshuawinsor Can you please elaborate on what security concerns may be caused, or any active issues that someone faced. As I am using GIT_SSH_COMMAND="ssh" npm ci as a workaround. Is there any other way?

[joshuawinsor]

the default ssh implementation is the following in order taking the first one that comes up

commandline options ~/.ssh/config /etc/ssh/ssh_config StrictHostChecking=yes

This overrides all of that to use a weaker security model than the default (and you may not think it is that much weaker, but it is weaker otherwise ssh would set accept-new by default).

The proper way to do this for gitlab (or whoever it is that isn't properly doing their ssh server farm to maintain an ssh host id) to fix their implementation.

Until that point users should simply add that host to ~/.ssh/config to have StrictHostChecking accept-new

Also there are systems that I have used that make it difficult to set environment variables on all my npm commands. Again this makes ssh ignore what you have set for StrictHostChecking in your .ssh/config

[Alzy]

Currently facing this issue. I've tried exporting GIT_SSH_COMMAND=ssh but it did not work. I am trying this on AWS ElasticBeanstalk (Node.js 16 running on 64bit Amazon Linux 2/5.5.3) which runs OpenSSH_7.4p1. Am I missing something? I set the environment variable using the export keyword within hook inside of .platform/hooks/prebuild. Is there a different way to do this?

I also attempted to install the latest openssh using ebextensions but it complained that version 8 does not exist within the yum repos. Any help would be greatly appreciated

[colbygk]

Also facing this issue with the AWS shift from "Linux 1" to "Linux 2" in Elastic Beanstalk. AWS provides their own CVE updates to openssh, but they are still running a pretty old version of it in the "new" Linux 2 AMI:

OpenSSH_7.4p1, OpenSSL 1.0.2k-fips 26 Jan 2017

This breaks eb deploys if you have a package.json with a git reference to a package that your own org is deploying.

Other info about the AWS Linux 2 AMI:

[ec2-user@ip-10-2-3-240 ~]$ npm -version
8.5.5
[ec2-user@ip-10-2-3-240 ~]$ node --version
v16.15.0

[puka-tchou]

Just in case anyone is still struggling with this bug, you can also use this line:

GIT_SSH_COMMAND=ssh npm ci

It worked perfectly for me on the company dev servers.

---

Config:

• OpenSSH 7.4p1 Debian-10+deb9u7, OpenSSL 1.0.2u 20 Dec 2019
• git version 2.11.0
• npm version 8.11.0
• node v16.15.1

[orderwerks]

We ran into this same issue with an Amazon Linux 2 EC2 instance, and we used this gist to update our OpenSSH version to 8.x:

https://gist.github.com/roommen/18cd78d07b0fbc962de4e79c1d468f92

After updating, things worked again.

[serbaniuliuscezar]

https://issues.jenkins.io/browse/JENKINS-69149

Quote from the ticket:

markroland if the log file contains a reference to accept-new, then this is the issue you're seeing. Use "Manage Jenkins" -> "Configure Global Security" -> "Git Host Key Verification Configuration" to change the configuration from "Accept first connection" to "Known hosts file". No need to downgrade the plugin. No need to restart the Jenkins controller.

If that setting does not resolve it, then you can switch to "Manually provided keys" and provide the ssh host keys for the ssh servers you use.

If that setting does not resolve it, then you can switch to "No verification" and accept that you've reintroduced the man in the middle attack vector.

Another shameless plug from me that you'll have better results if you move to a different operating system as your time and your schedules allow. CentOS 7 is supported but the utilities included in CentOS 7 are very old versions, including command line git 1.8.3.