# Server provisioning works but deploy doesn't

**URL:** https://discourse.roots.io/t/server-provisioning-works-but-deploy-doesnt/9406
**Category:** trellis
**Created:** 2017-04-18T08:53:35Z
**Posts:** 7
**Showing post:** 6 of 7

## Post 6 by @fullyint — 2017-04-18T16:29:59Z

In other contexts, I’ve heard people express frustration about having to switch to more secure host keys, so here are a few more notes to help people understand and take control of their situation. See also this [overview of SSH keys and known\_hosts](https://discourse.roots.io/t/known-hosts-yml-headaches/8867/4).

* * *

The host key the server offers is based on what your local machine **SSH client** requests and what the **server** is allowed to offer (per its configuration).

Trellis doesn’t cause regeneration of host keys, but the Trellis default configures the server to offer only the most secure host key types (ed25519 or rsa). If you have to change host keys, it means that an older less secure host key type (probably ecdsa type) slipped in to your known\_hosts, probably because you built the server with a Trellis version prior to [roots/trellis#744](https://github.com/roots/trellis/pull/744) (back when the **server** didn’t control key type) or made your first SSH connection to the server manually instead of via Trellis and your **SSH client** didn’t control key type.

You could configure your `~/.ssh/config` SSH client in your local machine to only request secure host key types and never again have an issue (i.e., specify preferred [`HostKeyAlgorithms`](http://manpages.ubuntu.com/manpages/xenial/en/man5/ssh_config.5.html)). If your `ssh -V` shows version 6.5 or newer, you may specify both the ed25519 and rsa types. If older, the rsa types only. ([example lists](https://github.com/roots/trellis/blob/1f165ead7b22d8dd1dd88294ae4d7c71849b5a74/roles/connection/defaults/main.yml#L5)).

Even if you haven’t specified secure `HostKeyAlgorithms` in your own `~/.ssh/config`, Trellis does what it can to prevent host key changes, trying to help you get a secure host key type (ed25519 or rsa) from the very beginning with new servers. There are details in [roots/trellis#798](https://github.com/roots/trellis/pull/798) about how Trellis tries to help you use secure host keys with minimal inconvenience (via a one time `HostKeyAlgorithms` SSH connection option). If your known\_hosts happens to have the less secure ecdsa host key type, it’s a one-time procedure per server to a change to a more secure key for that server (update key type in known\_hosts).

* * *

If someone doesn’t care for security, but only convenience, and doesn’t want to adjust `HostKeyAlgorithms` in `~/.ssh/config`, here is a workaround (not recommended). The `sshd` role README describes how to [customize [the sshd role] via variables](https://github.com/roots/trellis/tree/1f165ead7b22d8dd1dd88294ae4d7c71849b5a74/roles/sshd#customize-via-variables):

> You may redefine any variable found in `templates/sshd_config.j2` or `templates/ssh_config.j2`. The default settings are viewable in `defaults/main.yml`. To override a setting, you could redefine your chosen variable in a file such as `group_vars/all/main.yml` or `group_vars/all/security.yml`.

The relevant variable to redefine in the case of host keys is [`sshd_host_keys`](https://github.com/roots/trellis/blob/1f165ead7b22d8dd1dd88294ae4d7c71849b5a74/roles/sshd/defaults/main.yml#L34-L36). You would need to add back the less secure ecdsa type. Trellis doesn’t regenerate host keys, but this setting tells your server which of its host keys it is allowed to offer SSH clients that are trying to connect. Here is an example of allowing the server to offer the less secure ecdsa host key type:

```
# group_vars/all/main.yml -- this is less secure
sshd_host_keys:
  - /etc/ssh/ssh_host_ecdsa_key
  - /etc/ssh/ssh_host_ed25519_key
  - /etc/ssh/ssh_host_rsa_key
```

---

_[View the full topic](https://discourse.roots.io/t/server-provisioning-works-but-deploy-doesnt/9406)._