fix: default to accepting new ssh host key fingerprints

[nlf]

currently, if a user tries to use npm to install a git repository over ssh from a host that does not already exist in their ~/.ssh/known_hosts a prompt is half displayed and the install appears to hang. pressing enter when this happens does unblock the install, but the behavior is super strange.

this change requires a git version > 2.3 and an openssh version > 7.6 but is a reasonably safe default as it will accept new host fingerprints without prompting, but hosts that exist in your ~/.ssh/known_hosts will be verified and fail if they mismatch.

this default behavior can be overridden by either of

• configuring core.sshCommand in your ~/.gitconfig
• exporting your own value for GIT_SSH_COMMAND

I'll see if I can get an installation of something up and running with an older openssh to see how it's handled if the accept-new value isn't supported. older versions of git aren't a concern since they would simply ignore the env var and maintain the current behavior.

References

Related to npm/cli#2741

[riccardomessineo]

For future reference, I was struggling with the "accept-new" unsupported option due to this PR.
To fix it, I've tried to use core.sshCommand in .gitconfig but it was ineffective. Instead, setting the env variable worked fine.

https://git-scm.com/docs/git-config#Documentation/git-config.txt-coresshCommand
core.sshCommand
If this variable is set, git fetch and git push will use the specified command instead of ssh when they need to connect to a remote system. The command is in the same form as the GIT_SSH_COMMAND environment variable and is overridden when the environment variable is set.

[wraithgar]

Thanks @riccardomessineo I'll copy this comment to the cli issue too since that repo is searched more often.

[riccardomessineo]

Thank you for the support 👍

[joshuawinsor]

This breaks a significant number of environments, wouldn't this be better set in end users ~/.ssh/config which this will now override?