linode_destroy.yml currently has a task that clears a linode from ~/.ssh/known_hosts when we destroy it. If we did not do this, and you re-created a linode with the same name, SSH would freak out and refuse to let you connect, warning you of potential man-in-the-middle attacks. (It's possible that using SSH aliases would have some effect on this issue?)
Unfortunately, linode_create.yml is not currently aware of this issue, and so if a linode is destroyed using a method that is not linode_destroy.yml, such as Linode's web control panel, ~/.ssh/known_hosts will not be cleared, and the playbook will not run successfully if you re-create the server with the same name.
We should write a task that checks if the SSH known hosts file is correctly configured, and fixes it if it is not.
Another way to dodge this issue would be to create an SSH CA so that we're not relying on TOFU, so our known hosts would be updated by the CA, presumably.
linode_destroy.yml currently has a task that clears a linode from ~/.ssh/known_hosts when we destroy it. If we did not do this, and you re-created a linode with the same name, SSH would freak out and refuse to let you connect, warning you of potential man-in-the-middle attacks. (It's possible that using SSH aliases would have some effect on this issue?)
Unfortunately, linode_create.yml is not currently aware of this issue, and so if a linode is destroyed using a method that is not linode_destroy.yml, such as Linode's web control panel, ~/.ssh/known_hosts will not be cleared, and the playbook will not run successfully if you re-create the server with the same name.
We should write a task that checks if the SSH known hosts file is correctly configured, and fixes it if it is not.