A developer maintained fourteen separate scripts that performed deployment, service restarts, DNS changes, and mail diagnostics against a production VPS. Each script contained its own copy of the target IP address, a classic copy-paste pattern that survived until the provider migrated the instance.
After the move the old address was promptly reassigned to another customer. Instead of fourteen connection timeouts, every script established an SSH session to the new owner’s server and transmitted the root password stored in the environment variable VPS_PASS.
What AutoAddPolicy Actually Does
When an SSH client connects, the server presents its host key. The client compares this key against entries in known_hosts. A mismatch normally produces the warning “REMOTE HOST IDENTIFICATION HAS CHANGED!” and aborts the session. AutoAddPolicy replaces this check with an unconditional acceptance of any key, eliminating both the warning and the protection.
The policy is often described only as defense against man-in-the-middle attacks. In cloud environments the more immediate risk is simple IP reassignment: the provider reclaims the address and hands it to the next tenant without malice or interception.
Three Required Fixes
- Load system and user host keys explicitly and enforce RejectPolicy so that an unknown or changed key raises an exception before any credentials are sent.
- Store the target address in a single shared module (vps.py) imported by all scripts, eliminating the possibility of fourteen stale copies.
- Prefer key-based authentication; fall back to password only when no key file exists. The private key never leaves the client, so even an unintended connection yields nothing usable to the recipient.
The same trust problem appears when a web service fetches user-supplied URLs. The author’s checker therefore restricts requests to http and https, resolves names before connecting, rejects private, loopback, and link-local ranges, and re-validates after every redirect.
Smoke tests confirm that attempts to reach 127.0.0.1, 169.254.169.254, and file:///etc/passwd are blocked. The incident shows that disabling host-key verification is not a harmless convenience; it is the removal of a control that becomes critical the moment an IP address changes ownership.
