Part 1: Certificates
I read up on how to use ssh certificates. I still ran into a couple of surprises:
My known_hosts file is hashed. The easiest way to figure out the entry for the server is to connect with
ssh -v and look for the message where the host key was found "in known_hosts:4". That means line 4 of the file. But, it also includes the whole key for lookup, such as
'[server.example.org]:222' for sshd listening on a non-standard port. With that, you can use the official command instead of counting line numbers:
ssh-keygen -R '[server.example.org]:222'
Another part I did not understand going into this, is that the certificate doesn't replace the keypair. It certifies the keypair. The keypair itself is still used, and it must be available to the client. Having been in computing for so long, it's odd for a word to have its actual English meaning.
As far as I can tell for creating the certificates, everyone is on their own for building a signing infrastructure. Which is why companies like smallstep or teleport will provide that piece, for a fee.
Part 2: Multiplexing
I finally got around to looking at sslh a bit, but it didn't exactly work.
Whether I start sslh or nginx first, the other thinks the address is already in use. But starting two netcat processes, one on 0.0.0.0:x and one on 127.0.0.1:x, seems to work fine. I could use nginx's stream module on my personal site, but the day job uses Apache, so I'm not sure how transferable all this is.
It would be nice to get it going from a "neat trick!" perspective, but it's not entirely necessary. Mainly, it would let us access our git repositories from corporate headquarters without having to request opening the firewall, but I've been there a total of one time.
Updated 2022-04-24: I ultimately chose to set up another hostname, using proxytunnel to connect, and having Apache terminate TLS and pass the
CONNECT request on to the SSH server. This further hides the SSH traffic behind a legitimate TLS session, in case it's not just port-blocking that we're facing.