This provides the user with a more OpenSSH-like experience as it reads from their ~/.ssh/config as expected, allowing for more advanced SSH links to the target devices.
This has some risk as it allows for more diversion between the HTTP endpoint used to check the status of the deployment and the target actually deployed onto, however this seems like a small risk in practise and the default case is unlikely to encounter this silently. More likely is that the user is on a network where they cannot easily see the HTTP endpoint and would end up bypassing that check anyway. If the mismatch becomes an issue we could always move to routing the state check through the SSH connection and/or requiring that it be opted-into.
This provides the user with a more OpenSSH-like experience as it reads from their
~/.ssh/configas expected, allowing for more advanced SSH links to the target devices.This has some risk as it allows for more diversion between the HTTP endpoint used to check the status of the deployment and the target actually deployed onto, however this seems like a small risk in practise and the default case is unlikely to encounter this silently. More likely is that the user is on a network where they cannot easily see the HTTP endpoint and would end up bypassing that check anyway. If the mismatch becomes an issue we could always move to routing the state check through the SSH connection and/or requiring that it be opted-into.
Fixes #4.