`flocker go` should setup all nodes to be able to SSH to each other about flocker HOT 8 CLOSED

Actually. ssh-copy-id doesn't less us specify an identity to use when connecting, so it might not work in the vagrant case.

Private key should go in /etc/flocker/private_key and then we can use permissions to ensure it's only root readable as first pass. And then code that needs to ssh to other nodes (typically the volume manager) can explicitly state the credentials it wants, which should make for less error prone functionality.

from flocker.

This should probably be done in three parts.

• Generate a key on each node to report back to the orchestrator.
• Add keys reported by the orchestrator from other nodes to authorized_keys.
• Write a wrapper program that prevents the added keys from doing arbitrary things.

from flocker.

Personally I was thinking of just doing this the stupid insecure way where you have one keypair you share with all of them, on the theory we'll be switching away from SSH within a release or two anyway. And just document "not secure, don't use in production".

from flocker.

Also note there may be some useful code for running openssh in my branch for #16 in a bit.

from flocker.

description updated with more detailed plan

from flocker.

As a testing strategy, use the Conch-based "run an SSH server" code from the volume push branch, point the API at that, and assert that good stuff happens locally as a result.

from flocker.

1. One thing that's missing here is which private key is used to SSH in to the nodes from developer laptop. Typically relying on user's existing keys would work... except Vagrant which defaults to a random key it generates. Possibly we can solve this by having the (still to be created) demo Vagrantfile use a real SSH key instead of the random one it uses. File a followup issue to figure that out, pretty sure it's just an easy config option.
2. File follow up issue to make our (still to be created) demo Vagrantfile allow ssh'ing in as root. Ditto for being an easy config option. (This and the previous one can be same issue of "configure demo vagrant for easy ssh-ing").
3. I'm a bit worried about functional testing strategy that can make developer desktops insecure if they're not using vagrant... I suggest having the root directory being an input to the entry point function, so you can run the tests against a sandbox area instead of global root directory.
4. I suggest storing the keypair in ~/.flocker/ on the admin laptop.
5. Please use GSSAPIAuthentiction=no, otherwise our demo will be super slow on Ubuntu desktops.

In general sounds good, please proceed.

from flocker.

I suggest having the root directory being an input to the entry point function, so you can run the tests against a sandbox area instead of global root directory.

I won't write any kind of tests that actually modifies anything in /root or /etc. The Conch server used by the functional tests can give the root user an alternate home - something from TestCase.mktemp() most likely. Then using the relative path .ssh/authorized_keys should be sufficient for the tests and real usage. Hmm. Using the same solution for /etc/flocker would mean using paths like ../etc/flocker which encodes assumptions about root's home directory...

Putting the key in root's home directory instead of /etc/flocker would side step this problem.

Please use GSSAPIAuthentiction=no, otherwise our demo will be super slow on Ubuntu desktops.

Argh argh argh argh argh.

from flocker.