Better dumping via private IP when bastion is not set

[justinsb]

Previously this would always fail in a confusing way,
regardless of whether we had connectivity,
because we tried to connect to an empty-string host.

Now we are more explicit about the error,
and will at least try to connect directly.

[justinsb]

The problem I'm trying to track down is this one from the bare-metal test:

2025/02/09 21:33:23 starting to dump 3 nodes fetched through the Kubernetes APIs
2025/02/09 21:33:23 Dumping node vm0
2025/02/09 21:33:23 could not dump node vm0: connecting: unable to SSH to "10.123.45.10": ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey], no supported methods remain
2025/02/09 21:33:23 Dumping node vm1
2025/02/09 21:33:23 could not dump node vm1: connecting: unable to SSH to "10.123.45.11": ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey], no supported methods remain
2025/02/09 21:33:23 Dumping node vm2
2025/02/09 21:33:23 could not dump node vm2: connecting: unable to SSH to "10.123.45.12": ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey], no supported methods remain

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: hakman

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [hakman]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment