What if you already run a web server which uses port 443? Strange that the readme doesn't mention that scenario because it's extremely common.
Presumably you'd choose a different port but then it'd be pretty obvious you're running something if your server has a random HTTPS server exposed on port 444 or whatever.
Can nginx proxy-pass encrypted data now? I tried this before and failed pretty hard, had to use HAproxy at the time and pass based on the hostname in the SNI header. Was still pretty unreliable.
If so, I assume the encryption on the SSH is handled separately from the http headers.
You can run different hosts on one web server, like company.com goes to localhost:5555 (your app or whatever) and ssh.company.com goes to localhost:8443 (let's say you're running ssh3 on that port)
* depending on your web server/reverse proxy configuration
[for instance, I run Kestrel and it really isn't designed to target more than one site; I do it, but it's like bending that Lego brick to make it fit where it shouldn't go]
That already has a (brutal) solution now - sslh https://www.rutschle.net/tech/sslh/README.html - the current version is more sophisticated, but it was originally just a perl script that would send the connection to sshd or the https web server, based on regex matching on an initial string (and I probably timing out and going to sshd if it didn't see one? Something like that, I haven't dug out the old code to check.)
SSHv2 is likewise trivially probable though ("nc $HOST 22" replies with "SSH-2.0-whatever"!), and that never hurt it. If you want to hide your services from attackers, there are many tools for that. I don't see why it needs to be part of the application protocol.
Presumably you'd choose a different port but then it'd be pretty obvious you're running something if your server has a random HTTPS server exposed on port 444 or whatever.