Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
When connecting to a git repository using ssh keys, there is a prompt u get when connecting for the first time:
similar to the one below:
The authenticity of host 'github.com (207.97.227.239)' can't be established.
RSA key fingerprint is 16:27:ac:a5:76:28:............etc.
Are you sure you want to continue connecting (yes/no)? yes
Currently you have to manually clone a repo first in oder to respond to this, it is not yet possible through the web interface.
Comments
Comment #1
Jon PughI've learned of the SSH option StrictHostKeyChecking. The example I tried was
ssh -oStrictHostKeyChecking=no user@host
.So then I googled how to pass SSH options to git and found the suggestion of using ~/.ssh/config, but that applies StrictHostKeyChecking
but I am not sure this is secure.
http://stackoverflow.com/questions/7772190/passing-ssh-options-to-git-clone
Would this be the best option to recommend? Is this insecure somehow? I am not sure we should force this for anyone, especially without thorough security review.
I think this might be something best left to the server admin installing devshop... however we should add some documentation about how to deal with SSH keys, and how to set this option up!
Comment #2
Jon PughNeed to add this to the documentation.
Comment #3
helmo CreditAttribution: helmo commentedPlease don't disable StrictHostKeyChecking, it's bad security.
One workaround would be to pre-seed ssh's known_hosts file. But that would only still work for common services like github.
Comment #4
Jon PughThanks for the tip, helmo, I wasn't sure about this.
I've added `StrictHostKeyChecking no` for drupal.org, github.com, bitbucket.org, acquia.com, and drush.in (Pantheon's servers) to 1.x and 2.x branches of the install script.
~/.ssh/config now looks like:
Setting to needs review until I get a second opinion!
Comment #5
helmo CreditAttribution: helmo commentedThis just limits the risk to the most commonly used services.
It make is that much easier to impersonate a git server and load unknown code on the managed server.
Comment #6
Jon PughDo you have any suggestions on this?
Should we simply tell people you must go through the manual first step of cloning a repo in order to authorize the host?
Comment #7
helmo CreditAttribution: helmo commentedAs I suggested in #3 you could ship some known good lines for the ssh known_hosts file.
Most projects handle it with documentation though.
One interesting, but unfortunately less adopted, ssh option is VerifyHostKeyDNS.
Comment #8
Jon PughI added SSH config for StrictHostKeyChecking false for known hosts...
I thought known_hosts used unique keys, so I wasn't aware we could ship with some known hosts.
Here's the line where I create the .ssh/config file:
https://github.com/drupal-devshop/devshop/blob/6.x-1.x/install.debian.sh...
Comment #9
Jon PughComment #10
jlmeredithI found the solution for me on this by reading where things failed during the verification. In my case it was when the command
git ls-remote
is called by DevShop. I logged in as the Aegir user, ran the command, accepted the key and things seemed to work well after this.Comment #11
Jon PughWe finished this in this PR https://github.com/opendevshop/ansible-role-aegir-user/pull/5/files