Adding support for password-based SSH authentication using `sshpass`.

[garnold]

All SSH-based (including SCP, rsync) now support an optional --password argument which enables password-based authentication. Passwords can also be stored in .overcast/clusters.json.

If a password is provided (via command line or clusters.json), it will take precedence over the SSH key.

This feature uses SSHPass[1][2] for password-based authentication, which is included in most Linux distributions, and can be installed on OS X with Homebrew or a simple ./configure && make && make install[3].

[1] http://sshpass.sourceforge.net/ [2] http://linux.die.net/man/1/sshpass [3] https://gist.github.com/arunoda/7790979

[garnold]

@andrewchilds What do you think?

[andrewchilds]

Nice work @garnold - let me look it over some more but so far so good :+1:

[garnold]

@andrewchilds Hold off on this pull... I think I found an issue with overcast run on this branch.

[garnold]

@andrewchilds Ok, fixed.

I also modified overcast instance update to unset the property in clusters.json if the property is set to an empty string.

[andrewchilds]

I'd prefer if the default behavior of the authorized_keys script was to overwrite ~/.ssh/authorized_keys but provide an option to append instead of overwrite. I'd also like to turn this into a command+script instead of a recipe+script. How about this?

Usage:
  overcast key push [instance|cluster|all] [name|path] [options...]

Description:
  Push a public SSH key to an instance or cluster. Accepts a key name,
  filename, or full path. This will overwrite the existing authorized_keys
  file, unless you use --append.

Options:            Default:
  --user USERNAME
  --append, -a      false

Examples:
  # Generate new SSH key pair:
  $ overcast key create newKey

  # Push public key to instance, update instance config to use private key:
  $ overcast key push vm-01 newKey
  $ overcast key use vm-01 newKey

  # Same as above but using key path instead of key name:
  $ overcast key push vm-02 ~/.ssh/id_rsa.pub
  $ overcast key use vm-02 ~/.ssh/id_rsa

  # Push public key to instance using arbitrary user:
  $ overcast key push vm-03 newKey --user myOtherUser

  # Append public key to authorized_keys instead of overwriting:
  $ overcast key push vm-04 newKey --append

Usage:
  overcast key use [instance|cluster|all] [name|path]

Description:
  Update an instance or cluster to use a particular SSH key, by name or path.

Examples:
  # Generate new SSH key pair:
  $ overcast key create newKey

  # Push public key to instance, update instance config to use private key:
  $ overcast key push vm-01 newKey
  $ overcast key use vm-01 newKey

This would make it easy to automatically regenerate keys and push them to a cluster:

dateTime=`date "+%m%d%y-%H%M%S"`
keyName="overcast-$dateTime" # e.g. overcast-011715-164932
overcast key create $keyName
overcast key push myCluster $keyName
overcast key use myCluster $keyName

[garnold]

@andrewchilds Even better! I just reverted db3dca0c8fa4dd1007f1fc782aff0e922ebe143a.

What's the difference between overcast key push and overcast key use? Is overcast key use just an alias of overcast instance update [name] --ssh-key PATH?

Also, I'm partial to the verb authorize, but that's just me.

[andrewchilds]

Is overcast key use just an alias of overcast instance update [name] --ssh-key PATH?

Correct, the problem is that instance update can only update a single instance at a time. Thinking about it some more, I think I should just make instance update work against multiple instances/clusters instead of adding key use. I'll still add key push though.

[garnold]

Ah got it, makes sense.

This pull no longer includes the key authorization stuff (the recipe/script were reverted; happy to rebase them completely out), and is purely about password-based SSH authentication. What do you think about merging it in?

[andrewchilds]

Well, there are security implications around using passwords instead of keys, but I'd rather be pragmatic and let people use passwords if that's how they want to connect to existing/imported instances. As for instances created using Overcast, keys are still the recommended and easiest way to go.

I'm going to merge this in and do a little cleanup, mostly around what to do if sshpass isn't installed. Thanks Geoff! :beers:

[garnold]

Much appreciated, thanks Andrew!

I'm with you on preferring keys. The motivation behind this pull was to be able to configure some NOOBS-based Raspberry Pis with SSH keys, since at first they can only be accessed by password.

FWIW the recipe/scripts for that are here: https://github.com/garnold/raspberry-pi-recipes

If there's anything there you might consider for the base Overcast package, let me know and I'd be happy to open up a pull.