SSH to IP instead of to fully qualified hostname: does this reduce MITM risk?

Question

I am applying configuration management to a VPS hosted by a VPS hosting company. Changing the hosting company is not an option, unfortunately.

This VPS has the following properties:

1. when newly-imaged or re-imaged, it generates a new, random, SSH public/private key-pair;
2. neither the VPS hosting company's web interface, nor the VPS hosting company's API, provide a way to replace that key-pair a known key-pair;
3. neither the VPS hosting company's web interface, nor the VPS hosting company's API, provide a way to obtain that key-pair's public key fingerprint;
4. the VPS host does not have signed (e.g. DNSSEC) DNS records;
5. the VPS hosting company's web interface and API do allow the VPS's IP address to be retrieved;
6. the VPS hosting company's web interface and API do use TLS, and have a valid certificate from a decent CA;
7. the VPS hosting company's web interface does allow an SSH client's public key to be uploaded, after which each time the VPS is re-imaged it will add that public key to a specified account's .ssh/authorized_keys file.

The first point above is normally a good thing, but coupled with the next two points, it means that it is impossible for the configuration management tool, when it attempts to log in to the VPS via SSH for the first time after the VPS has been re-imaged, to tell for sure whether the connection is being man-in-the-middled. In other words, the configuration management tool can, at best, use the trust-on-first-use ("TOFU") approach.

Normally, I would use a VPS's fully qualified hostname as the VPS's identifier in the configuration management tool, and I would avoid the need for TOFU by separately obtaining the VPS's SSH public key fingerprint out of band (e.g. via a secure API). With this particular VPS, though, the latter step is not possible.

As such, connecting via the fully qualified hostname seems to risk a MITM attack, e.g. via DNS spoofing, exploiting the fact that the configuration management tool would have to TOFU.

It seems to me that the most secure option here would be to fetch the VPS's IP address from the API over HTTPS, and have the configuration management tool SSH to that instead. At least this would avoid the DNS spoofing risk.

(Also, taking advantage of point 7 above will mean that even if a malicious server successfully masquerades as the VPS, at least the malicious server will not obtain the client's password or private key.)

Am I correct about this? Are there other risks, or better solutions, that I am overlooking?

Answer 1

Generally, using the VPS company's API is a good idea, given its proper reliability and also enough resources to implement and maintain that on your side. After all, the SSH key management functionality may be added to said API sooner or later (maybe even upon your feature request, who knows?).

However, DNS cache poisoning alone is, to put it mildly, a rare and complex attack. And in your particular case there's also a rather short attack window (between a VPS is created and assigned a FQDN, and the first attempt to log in), which requires either a perfect timing or an inside knowledge (or both) on an attacker's side. Moreover, virtual servers in most cases are assigned rather random and obscure FQDNs, and an attacker must guess that one, too.

Next, the VPS company's DNS servers most likely retrieve the FQDN of your VPS from a local configuration file or a database of some sort. Assuming that; if your ISP and all the transit ISPs between your resolver and the VPS company's network aren't doing any evil MitM attacks; if you're able to use the VPS company's DNS servers directly to resolve the FQDN of a newly created VPS; then the only place in the network where DNS cache poisoning could be theoretically applied is at your resolver. Therefore, given the nature of the DNS poisoning attack nowadays, it would be rather easy for you to detect and properly mitigate a DNS poisoning attempt.

Also, if your threat model includes attacks of that sort, be aware that Internet routing isn't any safer than DNS. Thus it might be a good idea to set up a dedicated VPS in the same location where all subsequent virtual servers would be allocated, so that the first use of a newly created VPS would be from a machine in the same network segment, eliminating a possibility of hijacking the allocated IP address.

ARP spoofing might also be harmful in roughly the same way, though it heavily depends on the respective virtual network architecture.

Despite all that, as I've pointed out, those attacks are rather hypothetical for an average Internet-facing service. Your mileage may vary; however, I'd better focus on proper monitoring and reporting to ensure that in case anything like that happens, you'll know about that as soon as it's possible.