Trellis: SSH HostKey algorithms different from native SSH can cause issues

[strarsis]

Submit a feature request or bug report

• [x] I've read the guidelines for Contributing to Roots Projects
• [ ] This is a feature request
• [x] This is a bug report
• [x] This request isn't a duplicate of an existing issue
• [x] I've read the docs and followed them (if applicable)
• [x] This is not a personal support request that should be posted on the Roots Discourse forums

---

Explicitly setting SSH HostKey algorithms in ansible config can cause issues with native ssh: https://github.com/roots/trellis/blob/master/ansible.cfg#L12

Both tools end up with a different HostKey algorithm to be used and
will complain about the changed HostKey that was inserted before by the other tool.

[fullyint]

The relevant commit: b24f074

Here is what happens if we do not specify HostKeyAlgorithms in ansible.cfg:

1. On first SSH connection with bare Ubuntu 16.04 box from DigitalOcean, server offers ECDSA key.
2. During provisioning, the sshd role limits server to offering ED25519 or RSA keys (not ECDSA).
3. On the next SSH connection (as different user, e.g., web for deploy, or admin_user after ControlPersist has timed out), server offers non-ECDSA host key, causing SSH client to warn of host key change.

The host key change issue is inevitable for servers provisioned prior to #744. Local known_hosts will have the ECDSA host key type but a Trellis updated with #744 causes the server to no longer offer ECDSA (because ECDSA is less secure). With servers provisioned prior to #744, the only way to avoid the host key change issue is to re-add the insecure ECDSA key to sshd_host_keys, but it's better to just deal with the host key change.

The good news is that the host key change issue IS avoidable for NEW servers if we tell the server to offer the ED25519 or RSA keys from the very beginning, as is done by specifying HostKeyAlgorithms in ansible.cfg. This works if your first SSH connection the new server is using Trellis. Of course, if you manually SSH first (without HostKeyAlgorithms), the server will default to offering the ECDSA key, loading your known_hosts with the ECDSA type, and you'll have to deal with the host key change later.

In summary, if bare servers default to offering the weak ECDSA type that we end up disabling, users will always have to deal with the host key change unless we can make the server offer the right key type from the beginning, which we try to do by specifying HostKeyAlgorithms in ansible.cfg.

I think the rationale is solid so I'm closing this issue, but if you see an error in my understanding, or a possible improvement, please let us know.