Turn StrictHostKeyChecking on for SSH

[nathanleclaire]

If you run something like docker-machine -D ssh dev ls you'll see the actual SSH command we are running behind the scenes:

$ docker-machine -D ssh dev ls
DEBU[0000] executing: ssh -o IdentitiesOnly=yes -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -o LogLevel=quiet -p 65069 -i /Users/nathanleclaire/.docker/machines/dev/id_rsa docker@localhost ls

Some of this looks OK (although we probably don't need the port forward to localhost any more), but instead of turning off strict host key checking (a security feature to prevent MITM attacks) we should probably be automatically adding the host to the user's known_hosts file instead. The -o StrictHostKeyChecking=no was probably OK for local VMs, but the whole game changes when we're SSHing out to machines on the public internet.

[ehazlett]

+1. I had the known_hosts stuff adding when we were using IdentityAuth.
I'll add this to the list. Thanks

On Thu, Feb 12, 2015 at 12:19 PM, Nathan LeClaire notifications@github.com
wrote:

If you run something like docker-machine -D ssh dev ls you'll see the
actual SSH command we are running behind the scenes:

$ docker-machine -D ssh dev lsDEBU[0000] executing: ssh -o IdentitiesOnly=yes -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -o LogLevel=quiet -p 65069 -i /Users/nathanleclaire/.docker/machines/dev/id_rsa docker@localhost ls

Some of this looks OK (although we probably don't need the port forward to
localhost any more), but instead of turning off strict host key checking
(a security feature to prevent MITM attacks) we should probably be
automatically adding the host to the user's known_hosts file instead. The -o
StrictHostKeyChecking=no was probably OK for local VMs, but the whole
game changes when we're SSHing out to machines on the public internet.

—
Reply to this email directly or view it on GitHub
#534.

[sthulb]

We could also drop shelling out to SSH.

[ehazlett]

Yes I'm planning this as part of the core refactor.

[sthulb]

Me too. Although it's a large bit of work in terms of security.

[sthulb]

Short term should be to implement this issue and then long term remove it in favour of our own client.

[nathanleclaire]

Wait, what would we do instead? I don't think we want to include a whole SSH / readline implementation in the machine code, why not use what's there?

[sthulb]

The crypto/ssh package will do 90% of the job.

[SvenDowideit]

or, pull ssh out entirely, and use docker run

[md5]

@nathanleclaire how were you thinking the host's SSH key would be retrieved to be added to known_hosts?

I was thinking it might be interesting to add SSH host keys to new machine hosts instead of allowing random keys to be generated and accepting them blindly. It looks like cloud-init supports this via the ssh_keys setting.

[ehazlett]

@md5 yes cloudinit does this. as a matter of fact, i used this in my cloudinit branch.

[md5]

👍

[sthulb]

My SSH branch will undo any changes to the existing implementation. I have host key checking in my branch.

[ehazlett]

@sthulb +1 -- i think we should handle this as part of the crypto/ssh refactor. How close is your branch to being ready?

[sthulb]

I just have to change 7 drivers and ensure host key checking actually works.

[ehazlett]

ah ok. thanks.

[jeanlaurent]

What should we do when we remove a machine, it would be better to remove it.
But then it starts to be complicated...

are we still willing to add the host to the known_hosts file ? cc @nathanleclaire

[nathanleclaire]

What should we do when we remove a machine, it would be better to remove it.
But then it starts to be complicated...

My suggestion would be that Machine should maintain and use its own known_hosts file when using OpenSSH (e.g. ~/.docker/machine/known_hosts). We could set it using -o UserKnownHosts and remove the relevant host line ourself when a user makes a rm call.

[brettdh]

Any updates on this issue? It seems like a pretty big deal, and it's been open for a long time now.