3 ms·

There is no doubt some number of SSH servers which have public domain names and/or public IP addresses, can accept DNS verification or running a completely unre

There is no doubt some number of SSH servers which have public domain names and/or public IP addresses, can accept DNS verification or running a completely unrelated HTTP server for IP verification, don't mind having their existence published in certificate transparency logs, don't care about or can separately handle client certs, and don't mind the SSH server restarting every ~month (until this gets shortened again) when the certificate is rotated. However, I would estimate the share of such sites at less than 5% of deployed SSH servers. The primary use case I can see here is to reuse an existing HTTPS cert for SSH on a box that already hosts a website. FWIW, there is an RFC for X.509 certificates in SSH, but it has not achieved wide adoption: https://www.rfc-editor.org/rfc/rfc6187 https://www.rfc-editor.org/rfc/rfc6187

kbolino 1y ago
(I have also responded to you in kragen's subthread, you may want to consolidate the discussion there)
vbezhenar 1y ago
More interesting statistics question is: how many connections over the world are opened to the servers with and without public domain/IP? I think that github alone makes a sizeable chunk of these connections. So if there was some better mechanism to establish trust before first handshake, that would benefit all of these connections. One approach that I could envision is to simply host ssh public key on some well known path (github.com/.well-known/ssh.pub) and ssh client will grab it over https before first connection and when key suddenly changes.
- deleted 1y ago
  [deleted]
- kbolino 1y ago
  I think your proposed solution is a great idea, but we're evaluating it at the wrong layer of the software stack. The real problem is Git(Hub)'s (mis-)use of SSH, not SSH itself per se. Adding full TLS and HTTP stacks to SSH clients would be massive bloat and a security/maintenance burden that OpenSSH, PuTTY, etc. probably don't want to take on. Whereas, it would be much easier for Git to add this functionality to its client, since it already has HTTPS support. I think we could also attack this problem from the angle of phasing out git+ssh protocol (or at least greatly reducing its use) by improving unattended/headless HTTPS user authentication.

kbolino 1y ago

(I have also responded to you in kragen's subthread, you may want to consolidate the discussion there)

vbezhenar 1y ago

More interesting statistics question is: how many connections over the world are opened to the servers with and without public domain/IP? I think that github alone makes a sizeable chunk of these connections. So if there was some better mechanism to establish trust before first handshake, that would benefit all of these connections. One approach that I could envision is to simply host ssh public key on some well known path (github.com/.well-known/ssh.pub) and ssh client will grab it over https before first connection and when key suddenly changes.

deleted 1y ago
[deleted]
kbolino 1y ago
I think your proposed solution is a great idea, but we're evaluating it at the wrong layer of the software stack. The real problem is Git(Hub)'s (mis-)use of SSH, not SSH itself per se. Adding full TLS and HTTP stacks to SSH clients would be massive bloat and a security/maintenance burden that OpenSSH, PuTTY, etc. probably don't want to take on. Whereas, it would be much easier for Git to add this functionality to its client, since it already has HTTPS support. I think we could also attack this problem from the angle of phasing out git+ssh protocol (or at least greatly reducing its use) by improving unattended/headless HTTPS user authentication.