Feature Request: Add custom known_hosts file to doctl compute ssh

[lawben]

As the title already says, I'd like to specify a custom known_hosts file as I would do with

> ssh -o UserKnownHostsFile=/tmp/known_hosts user@123.123.123.123 

Currently the doctl compute ssh command does not support this.

The main reason for this is an automated script that gets the IPs of all current droplets and calls ssh-keyscan on each one to avoid this interaction.

The authenticity of host '123.123.123.123' can't be established. 
Are you sure you want to continue connecting (yes/no)?

I would like to use this feature like this in a loop. The interaction of adding the host each time does not really work in that case.

for my-droplet-name in droplet-names; do
    doctl compute ssh --ssh-known-hosts /tmp/known_hosts \
                      --ssh-command "do stuff here" \
                      $my-droplet-name
done

In this case, /tmp/known_hosts was filled by another script beforehand.

I'd be willing to create a PR for this, if the feature is wanted. After a quick code check, it looks like it is more or less just passing arguments through the call stack

[lawben]

I've started to implement this feature (WIP here). For unix systems, this is pretty straightforward as we just need to pass the file to the native ssh command. For Windows however (or system that rely on ssh_internal), a bit of code is needed. There is an official knownhosts module that does most of the heavy lifting, but that currently does not support adding new keys if no matching one was found. So this results in ssh: handshake failed: knownhosts: key is unknown at the moment.

I see three options for this problems:

1. Support known_hosts only on unix systems
2. Write code to add unknown hosts to the provided file, just as unix ssh implementations do with "The authenticity of host xxx can't be established. ECDSA key fingerprint is xxx. Are you sure you want to continue connecting (yes/no)?"
3. Specify that if a known_hosts file is provided, it must contain the key for the given host or else it will fail.

The third option would suffice for my use case, as I always populate the file with the correct keys beforehand. I guess the second option is the cleanest, as the internal/external ssh commands would then both behave identically, but that means there would be some extra code dealing with adding these hosts. I'd be glad to write this though, if you guys think it's a useful addition.

Please let me know what your thoughts are on this.