[2.4.1][manual] juju ssh may use an incorrect address when multiple interfaces are present on a target machine

When add-machine is used with hostname as an argument instead of an IP address (maybe with IPs as well - I haven not checked) and multiple hostnames are present on a host `juju ssh` can use an incorrect address to try to ssh into the target host. This may also result in ssh fingerprint validation errors.

Example: a set of identical VMs is provisioned by an external too with docker pre-installed (the same bridge IP behind NAT is used).

host1 (juju controller, juju client) - controller model machine 0:

eth0: 192.0.2.1/24
docker0: 192.168.10.1/24
lo: 127.0.0.1

host2 (unit agent, machine agent) - default model machine 0:

eth0: 192.0.2.2/24
docker0: 192.168.10.1/24
lo: 127.0.0.1

host3 (unit agent, machine agent) - default model machine 1:

eth0: 192.0.2.3/24
docker0: 192.168.10.1/24
lo: 127.0.0.1

When machines are added to the model, docker0 IP is added to the list of machine IPs. When `juju ssh` is done from host1 as `juju ssh 0` or `juju ssh 1` it fails with fingerprint validation unless --no-host-key-checks option is used. If this option is specified the target machine is actually host1 because juju tries to iterate over IPs (failing hostname resolution for some reason, although DNS is configured properly per debug log) and uses docker0 IP as the target IP.

NOTE: the IP addresses on the target environment were different, so maybe IP address ordering is involved in this behavior as well.

To me this goes back to the lack of CRUD for network spaces and support for network spaces in the manual provider.

I also realize that this is a non-standard Ubuntu image scenario when something is pre-installed onto an Ubuntu image triggering a multi-homing scenario where Juju tries to find an ephemeral "private" address for a given machine and finds the docker0 bridge address in this particular case.