The pre-unlock state of the host should contain no secrets used during regular operation. But it must contain some secrets, both so that we can unlock it and so that it supports as much redundancy as possible even when locked
We want SSH access to the locked system so that we can unlock it manually, which means the host key(s) must live on unsecured storage. We should therefore not implicitly trust SSH connections to the locked system. A useful mitigation might be a second SSH server that is not started until after secure storage is available; post-unlock operations would not need to use the same host key as pre-unlock operations. Pre-unlock SSH connections could be restricted to unlocking commands; post-unlock SSH connections could be limited to VPN or other trusted sources
The locked system cannot provide any services, but it could proxy connections to a functional peer without needing any secrets. A pre-unlock firewall configuration could simply NAT to the peer until a post-unlock event (e.g. HA reports ready) triggers the normal firewall rules