bootstrap fails if "ssh" command is not available

I've been looking into what we can do here.

I've refactored utils/ssh to allow for multiple client implementations, and implemented the basics of two additional clients:
 - PuTTY (plink/pscp)
 - embedded go.crypto/ssh

I hit a stumbling block with PuTTY, as it does not support disabling strict host key checking. This is intentional; see http://www.chiark.greenend.org.uk/~sgtatham/putty/faq.html#faq-hostkeys
If we knew the public key ahead of time, that would be okay; as specified in the FAQ, we could prime the Windows registry before calling into PuTTY. Similarly, we could prime .ssh/known_hosts and do away with the StrictHostKeyChecking=no option.

One option then is to specify the private key that the machine should use. We then have a well known public key which we can verify when connecting with SSH. The problem goes back to how we securely configure that key. If the ec2 user-data is not secure, then we should not store the private key there; if it can be obtained, then the host key checking is worthless as an attacker could poison DNS and impersonate the server.

There's some good discussion here about storing sensitive information in user-data: https://groups.google.com/forum/#!topic/ec2ubuntu/7TpLuyCDcyw

I think the most reasonable thing to do is to use "disable_ec2_metadata" in our cloud-config.

-----

As mentioned, I've also looked into using go.crypto/ssh as a client. I hit a bug (http://code.google.com/p/go/issues/detail?id=6088), but it generally seems to be working fine. There's some finessing to do around formatting the commands correctly, as commands need to be formatted as a single string, and that string will "typically" be interpreted by a shell.

Next problem: go.crypto/ssh specifies the smallest possible maximum packet length for channel requests. We write some fairly long commands during bootstrap. I'll see if we can improve that situation.

We can fix the above-mentioned problem if we address lp:1261343, since then sshinit can operate without any need for sudo prompting. Then we can pass the script via stdin, rather than on the command line.