Known_hosts.yml headaches

trellis
4

To undo the effects of roots/trellis#751, in group_vars/all/known_hosts.yml . . .

  • keep the default repo_accept_hostkey: true
  • set known_hosts to an empty list, e.g., known_hosts: []

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 users.

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 '12.34.56.78 (12.34.56.78)' 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:
ssh-keyscan github.com
You’ll see that this output matches what Trellis lists for GitHub in known_hosts.yml:

github.com ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAq2A7hRGmdnm9tUDbO9IDSwBK6TbQa+PXYPCPy6rbTrTtw7PHkccKrpp0yVhp5HdEIcKr6pLlVDBfOLX9QUsyCOV0wzfjIJNlGEYsdlLJizHhbn2mUjvSAHQqZETYP81eFzLQNnPHt4EVVUh7VfDESU84KezmD5QlWpXLmvU31/yMf+Se8xhHTvKSCZIFImWwoG6mbUoWf9nzpIoaSjB+weqqUUmpaaasXVal72J+UX2B+2RPW3RcT0eOzQgqlJL3RKrTJvdsjE3JEAvGq3lGHSZXy28G3skua2SmVi/w4yCE6gbODqnTWlg7+wC604ydGXA8VJiS5ap43JXiUFFAaQ==

The github.com host returns just one key of the rsa type, so known_hosts.yml lists only that one key.

The gitlab.com host returns keys of three types: rsa, ecdsa, and 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 gitlab.com.

Your questions.

  1. 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.

  2. The name is the domain name involved in the expected connection, no protocol or git@. If the connection will be to git@gitlab.mydomain.com:myname/site1.com.git then the key name should be gitlab.mydomain.com.

  3. 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 ssh-keyscan command.

  4. 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?”

  5. 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 wordpress_sites.

    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, the 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.

known_hosts:
  - name: github.com  # all keys for github.com will be removed -- because `key` is missing
    state: absent
  - 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
    state: absent
7 Likes