3 ms·

This is fun but a more practical solution would be for “ssh host” to GET the host’s public key from https://host/.well-known/ https://host/.well-known/. The Op

This is fun but a more practical solution would be for “ssh host” to GET the host’s public key from https://host/.well-known/ https://host/.well-known/. The OpenSSH daemon could host it for you if you could fit a tiny, vuln free httpd inside it — not an enormously onerous task given that the codebase already includes the implementation of a robust TCP daemon. Add ACME support and you’ve moved the TOFU MITM attack from being possible on every-new-client-connection to also having to coincide with the once-every-X-days for the HTTPS certificate renewal. It’s a lot of new functionality which probably isn’t cool for the OpenSSH codebase, but it’s a pragmatic solution to plugging the gap between mankind’s universally deployed PKI and ssh’s ephemeral peer-to-peer verification.

CGamesPlay 4y ago
Doesn't SSH already support using TLS keys for authentication? So, we can skip the whole HTTPS part of the equation.
- t0mas88 4y ago
  Jup, it does. And that was my first thought reading this as well.
- jleahy 4y ago
  No it has its own certificate system, it’s not TLS and it’s not even X.509.
  - growse 4y ago
    Not being x.509 is arguably a good thing. :)
AndyMcConachie 4y ago
Making SSH authentication dependent on HTTPS seems like a really bad idea.
- kedihacker 4y ago
  Making ssh authentication dependent on honesty seems like a really bad idea.
- est 4y ago
  However I'd wish the reverse is true, SSH via TLS connections, so I don't need to open another 22 port, and make my SSH hidden behind Cloudflare or something.
chrisandchris 4y ago
So one needs to run an HTTP-Server for a host that only has SSH otherwise? > but it's a pragmatic ... I think we have different views of the word pragmatic if your pragmatic solution covers including a HTTP server in OpenSSH for serving a single (!) file while the other solution depends on something you most probably already use to connect to the server (DNS).
- gorgoiler 4y ago
  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.
- deleted 4y ago
deleted 4y ago
[deleted]
est 4y ago
> not an enormously onerous task given that the codebase already includes the implementation of a robust TCP daemon. Yeah then you got at least two more problems. SSL and OCSP

CGamesPlay 4y ago

Doesn't SSH already support using TLS keys for authentication? So, we can skip the whole HTTPS part of the equation.

t0mas88 4y ago
Jup, it does. And that was my first thought reading this as well.
jleahy 4y ago
No it has its own certificate system, it’s not TLS and it’s not even X.509.
- growse 4y ago
  Not being x.509 is arguably a good thing. :)

AndyMcConachie 4y ago

Making SSH authentication dependent on HTTPS seems like a really bad idea.

kedihacker 4y ago
Making ssh authentication dependent on honesty seems like a really bad idea.
est 4y ago
However I'd wish the reverse is true, SSH via TLS connections, so I don't need to open another 22 port, and make my SSH hidden behind Cloudflare or something.

chrisandchris 4y ago

So one needs to run an HTTP-Server for a host that only has SSH otherwise? > but it's a pragmatic ... I think we have different views of the word pragmatic if your pragmatic solution covers including a HTTP server in OpenSSH for serving a single (!) file while the other solution depends on something you most probably already use to connect to the server (DNS).

gorgoiler 4y ago
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.
deleted 4y ago

deleted 4y ago

[deleted]

est 4y ago

> not an enormously onerous task given that the codebase already includes the implementation of a robust TCP daemon. Yeah then you got at least two more problems. SSL and OCSP