I found awesome walkthroughs describing how to configure Vault to create an SSH Root CA and sign user public keys so they can login to a host holding the Root CA public key. However, I would like to have an intremediate (Subordinate) SSH CA. I want the Intermediate CA to sign the user certificate signing request so that I can take the Root CA offline (air-gapped) to protect it from cyber attacks. That way, when my Intermediate CA is compromised I can simply destroy the Intermediate CA, create a new one using the Root CA and sign user certificate signing requests using that new Intermediate CA without having the need to install new Root CA public keys on the hosts my users want to access. Vault provides walkthroughs to setup Sub CA for PKIs but cannot find one to setup Sub CA for SSH. Anyone any hints how to configure what I am looking for?
That’s because the SSH CA system doesn’t have intermediate CAs at all.
Dear @maxb, thanks for your reply! Any suggestions from your side? My main concern is protecting the private key of the Root CA because we have use cases where our devices cannot be accessed remotely and hence we cannot replace the Root CA public key when needed.
That is a legitimate concern, but as @maxb said, SSH was not built that way. Nothing to do with Vault. If possible, you could shorten the window of attack by having the server call home and update the root CA certificate. But then you must validate the certificate of the host certificate and/or check the signature of the package you will be downloading, both of which can be compromised by another CA key leak… 
You could get better protection of the SSH CA’s private key using Managed Keys in Vault Enterprise, but it is not supported by the SSH CA as I write this (version 1.14.1).
Not an ideal solution, but you should consider its risk through impact and likelihood. The likelihood of the CA key leak is “remote” or “unlikely”. The likelihood of having outdated or hard-to-manage authorized_keys files everywhere is “likely” to “almost certain”. The impact is should be about the same, maybe a little higher for the key leak scenario. You’ll probably end up with a SSH CA being the lowest risk solution.
Thank you @ixe013 for your extensive answer! Yes it is a bit of a struggle, we want to do the right thing but not introduce something that is a pain to maintain. Nevertheless, your input is very insightfull for us making the right decisions.
I’m testing the SSH signed certificates right now, after unsuccesfully trying the SSH OTP solution a few weeks ago. I find the SSH “ROOT” CA definition somehow misleading, as the SSH signing CA is different from the ROOT CA in a X509 PKI ecosystem.
If you use Vault to sign the user’s SSH key and get the relative certificate, the signing CA key lives inside Vault. I agree with @ixe013, likelihood of the CA key leak is “remote” as it’d mean Vault is compromised, a much worse concern imho.