Return to Answer

If you really want to keep CheckHostIP, you can turn it back on and disable it only for hosts with dynamic IPs to skip the warning and known_hosts pollution. Don't do this, though. It's not that helpful.

It seems pretty unlikely that CheckHostIP is a meaningful measure for dealing with a threat actor who can both…

In the face of such a foe, it seems ludicrous that somehow you'll be saved by the "Warning: Permanently added host key" message when connecting to a host, especially when it shows you the warning² every single time.

In order to cut down on the super-long known_hosts entries, other people simulate IP ranges with wildcards, which may appear clever, but it's actually finicky³ and only works because CheckHostIP checks IPs and ignores hostnames.

_{¹ For some reason, this post ranks fairly high in search results for real host key leaks.
² That is to say: "when it cries 'Wolf!'"
³ For example, if you try to allow 127.0.0.* for your dynamic-IP SSH server, you technically also match 127.0.0.evilsite.example because IPs and hostnames are not distinguished. You can limit wildcards to single characters with ?, but be careful: 127.0.0.?? will match 127.0.0.cz. Maybe it seems unlikely that .cz would allow 0 as a second-level domain, but we're talking about an adversary who is poisoning your DNS!}

If you want to keep CheckHostIP, you can turn it back on and disable it only for hosts with dynamic IPs to skip the warning and known_hosts pollution. Don't bother doing this, except in extreme circumstances. It's not that helpful. CheckHostIP is an underwhelming measure for dealing with a threat actor who can both…

In the face of such a foe, it seems ludicrous that somehow you'll be saved by the "Warning: Permanently added host key" message when connecting to a host, especially when it shows you the warning² every single time.

In order to cut down on the super-long known_hosts entries, other people simulate IP ranges with wildcards. This only works because CheckHostIP checks IPs and ignores hostnames. If it did the checks like it does on hostname, you'd be sunk.³

_{¹ For some reason, this post ranks fairly high in search results for real host key leaks.
² That is to say: "when it cries 'Wolf!'"
³ For example, if you try to list 127.0.0.* in known_hosts for your dynamic-IP SSH server, you technically also match 127.0.0.evilsite.example because IPs and hostnames are not distinguished. You can limit wildcards to single characters with ?, but be careful: 127.0.0.?? will match 127.0.0.cz. Maybe it seems unlikely that .cz would allow 0 as a second-level domain, but we're talking about an adversary who is poisoning your DNS!}

It is so improbable that CheckHostIP is a meaningful measure for dealing with a threat actor who can both…

In order to cut down on the super-long known_hosts entries, other people simulate IP ranges with wildcards, which may appear clever, but it's actually finicky and it only works because CheckHostIP works against IPs and ignores hostnames.³

It seems pretty unlikely that CheckHostIP is a meaningful measure for dealing with a threat actor who can both…

In order to cut down on the super-long known_hosts entries, other people simulate IP ranges with wildcards, which may appear clever, but it's actually finicky³ and only works because CheckHostIP checks IPs and ignores hostnames.

In my view, CheckHostIP just reassures you that an attacker who has already compromised your remote server's private key hasn't also poisoned your local DNS.

Leak instructions

If you found this post because of a remote server's host key leaking, follow the instructions from the service provider to cycle the relevant known_hosts entries. You may also want to remove the matching lines from known_hosts that CheckHostIP has added.

In the face of such a foe, it seems ludicrous that somehow you'll be saved by the "Warning: Permanently added host key" message when connecting to a host, especially when it shows you the warning¹ every single time.

Some people proactively dump all the known IPs for a service into a known_hosts line. I think they're doing this just to avoid the warning message. It front-loads all the nonsense into known_hosts that you'd gradually accumulate otherwise. But frankly, the important part of known_hosts is not the IP, it's the host key.

In order to cut down on the super-long known_hosts entries, other people simulate IP ranges with wildcards, which may appear clever, but it's actually finicky and it only works because CheckHostIP works against IPs and ignores hostnames.²

_{¹ That is to say: "when it cries 'Wolf!'"
² For example, if you try to allow 127.0.0.* for your dynamic-IP SSH server, you technically also match 127.0.0.evilsite.example because IPs and hostnames are not distinguished. You can limit wildcards to single characters with ?, but be careful: 127.0.0.?? will match 127.0.0.cz. Maybe it seems unlikely that .cz would allow 0 as a second-level domain, but we're talking about an adversary who is poisoning your DNS!}

In my view, CheckHostIP just reassures you that an attacker who has already compromised the remote server's private key hasn't also poisoned your local DNS.

Side Note: Leak instructions

If you found this post because of a remote server's host key leaking,¹ follow the instructions from the service provider to cycle the relevant known_hosts entries. You may also want to remove the matching lines from known_hosts that CheckHostIP has added.

In the face of such a foe, it seems ludicrous that somehow you'll be saved by the "Warning: Permanently added host key" message when connecting to a host, especially when it shows you the warning² every single time.

Some people proactively dump all the known IPs for a service into a known_hosts line, probably just to avoid the warning message. That front-loads all the nonsense into known_hosts that you'd gradually accumulate otherwise, but I think it's missing the point: The important part of known_hosts is not the IP—it's the host key.

In order to cut down on the super-long known_hosts entries, other people simulate IP ranges with wildcards, which may appear clever, but it's actually finicky and it only works because CheckHostIP works against IPs and ignores hostnames.³

_{¹ For some reason, this post ranks fairly high in search results for real host key leaks.
² That is to say: "when it cries 'Wolf!'"
³ For example, if you try to allow 127.0.0.* for your dynamic-IP SSH server, you technically also match 127.0.0.evilsite.example because IPs and hostnames are not distinguished. You can limit wildcards to single characters with ?, but be careful: 127.0.0.?? will match 127.0.0.cz. Maybe it seems unlikely that .cz would allow 0 as a second-level domain, but we're talking about an adversary who is poisoning your DNS!}