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?

  • This isa bit hard to follow. If you server has a valid certifcate the the ip address is resolved any way? why wouldn't you just use the ip address obtained when you connect to the htttps server? Technically if a public DNS was spoofing ip on packets for ssh port and not https port specifically to you server then it would be possible to MITM, the first connect. spoofing a public ip is hard because everyjump has to maliciously route it or your TCP/TLS tunnel will break
    – noone392
    Commented Jan 26, 2018 at 23:54
  • "why wouldn't you just use the ip address obtained when you connect to the htttps server?" The VPS hosting provider's website is served over HTTPS. The VPS is not. Nor do they have the same IP address. I'm sorry if I wasn't as clear as I should have been. I have now edited the question thus: s/VPS host/VPS hosting provider/ Commented Jan 26, 2018 at 23:59
  • 2
    aaa yes then I agree with you, if you could fetch the ips from a trusted channel then I would consider that a reasonable security.
    – noone392
    Commented Jan 27, 2018 at 0:03
  • 1
    I second the statment above ... if you fetch the ip from a trusted source I would consider that a reasonable security. If that is not enough, you can run a continuous ping and through the VPS provider bounce the node via https api ... if it goes down and comes up when you expect it too ... then you have 2 factor auth (something you have IP, and something you know when it would bounce) Commented Jan 27, 2018 at 5:27
  • Can you get the server to send you its fingerprint on first boot, instead of you requesting it? Commented Jan 28, 2018 at 6:35

1 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.

  • 1
    Unfortunately, the FQDN of the VPS is predictable. The rest of your points are well-taken. In particular, thank you for the link to the BGP hijacking article. I was sure there was some IP counterpart to DNS spoofing, but I was tired and could not bring it to mind. BGP hijacking is exactly what I was trying to think of :) Commented Jan 27, 2018 at 14:39

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .