5 ms·

And please, please, please add the fingerprint to that: <link rel="ssh" data-fingerprint="8b:16:df:7b:11:7c:78:1c:4d:65:3f:50:71:2b:91:5d" > Or whatever your

And please, please, please add the fingerprint to that: <link rel="ssh" data-fingerprint="8b:16:df:7b:11:7c:78:1c:4d:65:3f:50:71:2b:91:5d" > Or whatever your fancy, I don't care how, but please add that fingerprint. SSH displaying the user a fingerprint on first connect and allowing it to accept is its worst UI mistake.

stephenr 12y ago
Yet again, there is already a mechanism for this. Add your fingerprints to DNS (they can be obtained using ssh-keygen -r <hostname>) Set the SSH option VerifyHostKeyDNS to "yes" (or "ask" if you want to confirm, with a notice about if the DNS entry matches).
- pmh 12y ago
  That's not a secure option without DNSSEC. Given that we're unlikely to see significant DNSSEC adoption, serving the fingerprint over HTTPS (or another option altogether) would be preferable.
  - stephenr 12y ago
    So use DNSSEC for SSHFP lookups. The Debian package for example (openssh-client) added support for DNSSEC in its lookups, almost 5 years ago (April 2010)
- pb2au 12y ago
  The parent's suggestion would work if accessing the server by IP address directly, rather than DNS lookup. Assuming that the integrity of the data has been verified by the transport, I don't see the downside to the server providing the fingerprint in the HTML.
  - stephenr 12y ago
    The parent's "solution" assumes the browser is reading the markup and connecting directly to the SSH server. As I've said, this is a fucking horrible idea from a security stand point. This whole concept is bonkers given that client side certs already exist and already work, but if you have some reason to connect to SSH from a browser session (i.e. lets say you were providing a remote dev shell), a plain hyperlink that hands of the connection to the system's default "ssh" handler (i.e. a terminal app of some kind) is still the best solution here. Let the SSH client worry about SSH keys. Let the browser worry about HTTP and HTML.
    - pb2au 12y ago
      Sorry, I re-worded "solution" to the lighter "suggestion" after posting, and I agree that there is likely a more fool-proof architecture (e.g. one not vulnerable to XSS; even HTTP headers would be an improvement, I suppose). The idea (as I understand) is that you trust the data that you've received from the server, and the server knows the public key of the sshd that it wants you to use for login, so it provides the fingerprint for that public key. I agree that browsers shouldn't use SSH; it's overkill. But in the example (for humor), the browser does worry about SSH keys, because it is an SSH client. "Just use DNS with DNSSEC" won't work for direct IP addresses. Using client side certs is unnecessary, as the trusted web server is only telling you the conditions under which it is okay to authenticate. If you already trust the integrity of the data, it isn't more dangerous (from a security standpoint) than when you you get a page over HTTPS that tells you to POST to /login. Besides the fact that we both think that the browser as an SSH client is silly, I don't think the suggestion of providing the fingerprint in DNS with DNSSEC is any more secure than a trusted web server providing it, but it would not work for direct IPs.
      - stephenr 12y ago
        explain a real world scenario where you have a web server with a valid certificate but you don't have a DNS entry for the server? You're inventing ridiculous scenarios to justify a nonsense concept of integrating html, browsers and ssh.
        pb2au 12y ago
        explain a real world scenario where you have a web server with a valid certificate but you don't have a DNS entry for the server? For example, if the certificate is assigned to an IP address. Not extremely common, but some people use it. [1] You're inventing ridiculous scenarios to justify a nonsense concept of integrating html, browsers and ssh. I stated (twice) that I think having the browser act as an SSH client is a silly idea. Not sure how I'm interpreted otherwise. Both of my posts only point out that your intended correction (to just use DNS) wouldn't work for all cases, while the original post would work fine for authentication as far as I can tell. And that there are no inherent security concerns using in-band fingerprints, as opposed to looking them up via DNS w/ DNSSEC, if you already trust the integrity of the server response. You keep replying along the lines of "well it's a bad idea to do SSH in the browser anyways", and I've already agreed with you there, because you're correct. [1] https://support.globalsign.com/customer/portal/articles/1216536-securing-a-public-ip-address---ssl-certificates https://support.globalsign.com/customer/portal/articles/1216...

stephenr 12y ago

Yet again, there is already a mechanism for this. Add your fingerprints to DNS (they can be obtained using ssh-keygen -r <hostname>) Set the SSH option VerifyHostKeyDNS to "yes" (or "ask" if you want to confirm, with a notice about if the DNS entry matches).

pmh 12y ago
That's not a secure option without DNSSEC. Given that we're unlikely to see significant DNSSEC adoption, serving the fingerprint over HTTPS (or another option altogether) would be preferable.
- stephenr 12y ago
  So use DNSSEC for SSHFP lookups. The Debian package for example (openssh-client) added support for DNSSEC in its lookups, almost 5 years ago (April 2010)
pb2au 12y ago
The parent's suggestion would work if accessing the server by IP address directly, rather than DNS lookup. Assuming that the integrity of the data has been verified by the transport, I don't see the downside to the server providing the fingerprint in the HTML.
- stephenr 12y ago
  The parent's "solution" assumes the browser is reading the markup and connecting directly to the SSH server. As I've said, this is a fucking horrible idea from a security stand point. This whole concept is bonkers given that client side certs already exist and already work, but if you have some reason to connect to SSH from a browser session (i.e. lets say you were providing a remote dev shell), a plain hyperlink that hands of the connection to the system's default "ssh" handler (i.e. a terminal app of some kind) is still the best solution here. Let the SSH client worry about SSH keys. Let the browser worry about HTTP and HTML.
  - pb2au 12y ago
    Sorry, I re-worded "solution" to the lighter "suggestion" after posting, and I agree that there is likely a more fool-proof architecture (e.g. one not vulnerable to XSS; even HTTP headers would be an improvement, I suppose). The idea (as I understand) is that you trust the data that you've received from the server, and the server knows the public key of the sshd that it wants you to use for login, so it provides the fingerprint for that public key. I agree that browsers shouldn't use SSH; it's overkill. But in the example (for humor), the browser does worry about SSH keys, because it is an SSH client. "Just use DNS with DNSSEC" won't work for direct IP addresses. Using client side certs is unnecessary, as the trusted web server is only telling you the conditions under which it is okay to authenticate. If you already trust the integrity of the data, it isn't more dangerous (from a security standpoint) than when you you get a page over HTTPS that tells you to POST to /login. Besides the fact that we both think that the browser as an SSH client is silly, I don't think the suggestion of providing the fingerprint in DNS with DNSSEC is any more secure than a trusted web server providing it, but it would not work for direct IPs.
    - stephenr 12y ago
      explain a real world scenario where you have a web server with a valid certificate but you don't have a DNS entry for the server? You're inventing ridiculous scenarios to justify a nonsense concept of integrating html, browsers and ssh.
      - pb2au 12y ago
        explain a real world scenario where you have a web server with a valid certificate but you don't have a DNS entry for the server? For example, if the certificate is assigned to an IP address. Not extremely common, but some people use it. [1] You're inventing ridiculous scenarios to justify a nonsense concept of integrating html, browsers and ssh. I stated (twice) that I think having the browser act as an SSH client is a silly idea. Not sure how I'm interpreted otherwise. Both of my posts only point out that your intended correction (to just use DNS) wouldn't work for all cases, while the original post would work fine for authentication as far as I can tell. And that there are no inherent security concerns using in-band fingerprints, as opposed to looking them up via DNS w/ DNSSEC, if you already trust the integrity of the server response. You keep replying along the lines of "well it's a bad idea to do SSH in the browser anyways", and I've already agreed with you there, because you're correct. [1] https://support.globalsign.com/customer/portal/articles/1216536-securing-a-public-ip-address---ssl-certificates https://support.globalsign.com/customer/portal/articles/1216...