Hah, I’m surprised you zoomed in on that part. All you have to do for the protocol is blurt out “HTTP/1.1 200 OK\n\nssh-rsa AAAAf00fcafe…=“ on port 443 instead

Hah, I’m surprised you zoomed in on that part. All you have to do for the protocol is blurt out “HTTP/1.1 200 OK\n\nssh-rsa AAAAf00fcafe…=“ on port 443 instead of “SSH-2.0-OpenSSH_xyz EtcEtc” on port 22. I wouldn’t (and didn’t) suggest you include code to respond with the contents of files, nor should you even bother parsing the request*. The harder part is what is the client going to do? How will you implement TLS at each end? Your ssh client will want to link against an HTTP library that integrates with the client OS’s x509 PKI. That will be the axiom upon which your trust of the server is founded. OpenSSH’s client might trust their ssh host key because it was served in a connection signed by Let’s Encrypt, and the local copy of libcurl used libssl which found Let’s Encrypt in /etc/ssl/cacerts.pem etc etc. The hardest part is adding a TLS implementation to the OpenSSH daemon and the crazy part is having it support ACME so it can fetch its own certificates**. There is precedent for this though — caddy includes support for negotiating issuance and renewal of SSL certificates via ACME: https://caddyserver.com/ https://caddyserver.com/ Adding a new feature like this comes with the responsibility of supporting it in production and fixing bugs (in this case, dealing with weird missing features) for the remaining lifetime of the product. It’s not something to be done as lightly as an HN comment, by any means. There are a lot of sensible reasons to use DNS to bootstrap trust but as others have pointed out it is a little naive to think that DNSSEC has anything like the level of deployment that HTTPS has achieved since ACME and Lets Encrypt showed up. I contend that it’s that aspect which makes my solution indeed a more practical method — pragmatic, even — of bootstrapping trust over The Internet in 2023. * Yes, this will mean you cannot support clients that demand their content be encoded with xzip in ylang with zspace. We’re not writing a real httpd here, remember. ** If it’s using ACME HTTP then that makes the simplistic httpd a bit more complicated, of course. Now you have to blurt two responses instead of one.