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

Jon Pugh’s picture

Status: Active » Postponed (maintainer needs more info)

I'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!

Jon Pugh’s picture

Version: » 6.x-1.x-dev
Component: devshop_projects » Documentation
Priority: Normal » Critical
Status: Postponed (maintainer needs more info) » Needs work

Need to add this to the documentation.

helmo’s picture

Issue summary: View changes

Please 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.

Jon Pugh’s picture

Status: Needs work » Needs review

Thanks 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:

Host *drupal.org
    StrictHostKeyChecking no
Host *github.com
    StrictHostKeyChecking no
Host *bitbucket.org
    StrictHostKeyChecking no
Host *acquia.com
    StrictHostKeyChecking no
Host *drush.in.com
    StrictHostKeyChecking no

Setting to needs review until I get a second opinion!

helmo’s picture

This 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.

Jon Pugh’s picture

Do 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?

helmo’s picture

As 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.

Jon Pugh’s picture

I 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...

Jon Pugh’s picture

jlmeredith’s picture

I 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.

Jon Pugh’s picture

Status: Needs review » Fixed

We finished this in this PR https://github.com/opendevshop/ansible-role-aegir-user/pull/5/files

  - name: Pre-authorize known hosts.
    shell: "ssh-keyscan {{ item }} >> {{ aegir_user_home }}/.ssh/known_hosts"
    with_items: "{{ ssh_known_hosts }}"

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.