To undo the effects of roots/trellis#751, in
group_vars/all/known_hosts.yml . . .
- keep the default
known_hosts to an empty list, e.g.,
The other responses above are 100% correct, but here’s another angle. I’m making this broad and verbose for the sake of others who may come across this topic with similar questions.
Be clear on the difference between an SSH client’s key pair and an SSH server’s key pair.
Client key pair – establishes client identity. When you SSH to a server, your local machine is acting as the SSH client. The server establishes your identity by verifying a match between your private key and the public key the server has stored for you in its
authorized_keys file. You added this public key to the server either when you created the server, or if you listed the key in
Host key pair – establishes host identity. The client (your local machine) establishes the server’s identity by verifying a match between the host’s private key and the host’s public key your machine has stored in
known_hosts. You added this public key to
known_hosts when you made your very first connection to the server, when your CLI probably gave you a prompt such as this:
The authenticity of host '22.214.171.124 (126.96.36.199)' can't be established.
ED25519 key fingerprint is SHA256:...<snip>
Are you sure you want to continue connecting (yes/no)?
When your server acts as an SSH client. The deploy process causes your server to reach out to a git host and potentially to a composer package host. In that context, your server is acting as an SSH client and the git host or composer package host is acting as the SSH host.
For your server (now the SSH client) to establish the identity of these latter hosts (SSH servers), it needs those hosts’ keys in its own
known_hosts file. When
repo_accept_hostkey: true, your server will automatically accept the git host’s host key into your server’s
known_hosts, without just failing or prompting
Are you sure you want to continue connecting (yes/no)?.
If the deploy’s composer install process reaches out to a host not already in your server’s
known_hosts, the composer install will fail. Before roots/trellis#751 you would have had to SSH into your server and add those
known_hosts entries manually. The new Trellis
known_hosts allows you to specify those host keys right in your config, automating the process.
What should the host key entry look like? Find examples of how host keys should look by checking your local machine
known_hosts, either by opening and looking, or by using this command:
ssh-keyscan -H gitlab.mydomain.com
If you are on a machine that you trust has an uncompromised connection to a host, you can use this command to retrieve the host’s key:
You’ll see that this output matches what Trellis lists for GitHub in
github.com ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAq2A7hRGmdnm9tUDbO9IDSwBK6TbQa+PXYPCPy6rbTrTtw7PHkccKrpp0yVhp5HdEIcKr6pLlVDBfOLX9QUsyCOV0wzfjIJNlGEYsdlLJizHhbn2mUjvSAHQqZETYP81eFzLQNnPHt4EVVUh7VfDESU84KezmD5QlWpXLmvU31/yMf+Se8xhHTvKSCZIFImWwoG6mbUoWf9nzpIoaSjB+weqqUUmpaaasXVal72J+UX2B+2RPW3RcT0eOzQgqlJL3RKrTJvdsjE3JEAvGq3lGHSZXy28G3skua2SmVi/w4yCE6gbODqnTWlg7+wC604ydGXA8VJiS5ap43JXiUFFAaQ==
github.com host returns just one key of the
rsa type, so
known_hosts.yml lists only that one key.
gitlab.com host returns keys of three types:
ed25519. In a regular SSH connection (vs. this example
ssh-keyscan) there are a number of factors affecting which key a host will offer. One factor is the
HostKeyAlgorithms requested by the SSH client. Trellis configures your server’s SSH client to not accept the insecure
ecdsa type key from a host, which is why that type is missing from the key types preloaded for
Both types of host keys are listed to be ready for either type that
gitlab.com might send your server, depending on whether your server has been provisioned with the latest
sshd role and its updated
HostKeyAlgorithms (affecting which key types the
gitlab.com server may send). You’ll see that
HostKeys can be of various types, and which is selected can be affected by [
HostKeyAlgorithms] (http://manpages.ubuntu.com/manpages/xenial/en/man5/ssh_config.5.html) settings. Both keys are listed to avoid the error/warning that you would get if only one key were listed and the server offered the other type.
The name is the domain name involved in the expected connection, no protocol or
git@. If the connection will be to
firstname.lastname@example.org:myname/site1.com.git then the key
name should be
See the section above titled “What should the host key entry look like?” You should use the string you find in your own machine’s
known_hosts or the string from the
This is where I suspect you may be confusing the client key pair with the host key pair. See the section above titled “What should the host key entry look like?”
The host keys involved are typically for hosts like GitHub or Bitbucket and will almost never change. If you do have to add/remove a host key, it only matters that the change appears in the Trellis
known_hosts.yml file on your local machine. Although you should commit and push the change eventually, just for tracking, it will not affect your provision/deploy whether you’ve pushed that commit to the
repo you list in
For remote servers, only deploying adds a new key. So you don’t need to reprovision after adjusting the Trellis file
known_hosts.yml. Just deploy. For local dev Vagrant VM, do a regular
vagrant provision or run only the affected role by running:
ANSIBLE_TAGS=wordpress-install vagrant provision
If you wish to remove a host key from your server’s
known_hosts module docs point out that you may add
state: absent for a particular key. If you use
state: absent with no
key, it will remove all keys for the host with that
- name: github.com # all keys for github.com will be removed -- because `key` is missing
- name: gitlab.com # this key for gitlab.com will be kept
key: gitlab.com ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIAfuCHKVTjquxvt6CM6tdG4SLp1Btn/nOeHHE5UOzRdf
- name: gitlab.com # this particular key for gitlab.com will be removed
key: gitlab.com ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCsj2bNKTBSpIYDEGk9KxsGh3mySTRgMtXL583qmBpzeQ+jqCMRgBqB98u3z++J1sKlXHWfM9dyhSevkMwSbhoR8XIq/U0tCNyokEi/ueaBMCvbcTHhO7FcwzY92WK4Yt0aGROY5qX2UKSeOvuP4D6TPqKF1onrSzH9bx9XUf2lEdWT/ia1NEKjunUqu1xOB/StKDHMoX4/OKyIzuS0q/T1zOATthvasJFoPrAjkohTyaDUz2LN5JoH839hViyEG82yB+MjcFV5MU3N1l1QL3cVUCh93xSaua1N85qivl+siMkPGbO5xR/En4iEY6K2XPASUEMaieWVNTRCtJ4S8H+9