[stephenr]

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]

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/1216...

[stephenr]

> 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.

I'm purely talking about the concept of linking to SSH from a HTML page. The original concept of "http auth by anonymous SSH" is ridiculous, and I'm glad you agree with that.

So in terms of using a link to open an SSH session in general (lets assume a non-ridiculous use-case, like opening a session on a dynamically created remote environment).

I explained a solution that works right now, needs a couple of new DNS records and potentially a one-line change in the user's ssh config file, to provide automatic, safe acceptance of the fingerprint.

Your argument is that it won't work with an IP address, but that they might still have a TLS certificate for the server IP address, which implies that the person/organisation running the server, spent all their money on "ownership" of a public IP via RIPE NCC (apparently 1650 euro/year), and an expensive SSL cert ($350/year) tied to that IP, but that they can't afford a $10 domain name to make SSHFP over DNS (w/DNSSEC) work.

[pb2au]

but that they can't afford a $10 domain name

The reason they would spend the money on the ownership of the IP and cert isn't because they can't afford the domain name. It's generally done for "mission critical" reasons because it takes out a class of weaknesses. DNS hijacking, DNS servers failing, DNS blocking by governments, etc. It could even be for vanity reasons, they may self sign, or w/e. It doesn't really matter, because the chance that these servers are going to be serving HTML to your standard web browser is pretty slim.

But I still think it'd be weird for DNS to be used here.

Using DNS for this:

  https://1.1.1.1 -> ssh://1.1.1.1:443 -> cannot connect (or require manual override)
  https://example.org -> ssh://example.org:443 -> check fingerprint in DNS w/ DNSSEC -> connected

Using the in-band HTML or HTTP method:

  https://1.1.1.1 -> ssh://1.1.1.1:443 -> check fingerprint in trusted HTML/HTTP -> connected
  https://example.org -> ssh://example.org:443 -> check fingerprint in trusted HTML/HTTP -> connected

Assuming that the browser has already been modified to correctly handle whatever the SSH links do (e.g. by launching another program that has the fingerprint added) and the SSH link meets some security checks (same common name, same port running both the httpd and sshd), it seems wrong to me to have different capabilities based on if the common name is an IP address or a FQDN. I see the DNS solution to be kind of a "if all you have is a hammer..." solution, rather than a tailored solution for the link handling.

Anyways, thanks for the follow up post, I think I see your POV and agree with you that the DNS method would require much less work in order to get it work, given the current implementation.

[stephenr]

The DNS solution has the benefit of working regardless of how the session is initiated.

I also don't see any benefit to domain/port matching. It's a different protocol, it should be treated as such

[pb2au]

The DNS solution has the benefit of working regardless of how the session is initiated.

But only for domains. Whereas the browser handling could say that the trusted-web-server on (common name) told me that X is a valid fingerprint for the sshd running on this same (common name). That sshd that runs on that port is customized and might create, like you mentioned earlier, a dynamically-created remote environment for the user.

If there were many web-servers/dynamic-sshd instances on a single domain, all the fingerprints would need to be added to the DNS. Granted, a unique use-case.. but the flexibility of browser handling would be nice.

The (common name) matching would be necessary as a same-origin policy.

edit: Basically, since the browser can understand the rest of the HTML/HTTP on the trusted page along with the ssh://name?fingerprint link, I think it makes sense to leverage it when wanting to open a connection to the same name, rather requiring the name to be a domain name and using DNS to get those values. For ssh:// links that aren't the same (common name) you wouldn't be able to use fingerprints (similarly to how you wouldn't be able to use fingerprints to the DNS entry for them).

On second thought, the port wouldn't matter, just the common name, since you've got a cert for it.

[stephenr]

> But only for domains.

I would argue that currently almost 100% of SSH sessions would be started in a manner that has nothing to do with HTML or a browser. In that scenario there is no alternative to SSHFP + DNSSEC, and it's available to use today.

Given that the original concept proposed for HTTP auth over SSH is accepted as ridiculous, the number of use-cases for opening a SSH session from a browser is still minimal, and even then, those clients can also get the benefits of SSHFP + DNSSEC the same as regular sessions.

> That sshd that runs on that port is customized and might create, like you mentioned earlier, a dynamically-created remote environment for the user.

That wasn't at all what I meant - I meant that you might offer a web UI to create a new remote environment for a person to use, and then provide a shortcut "login with SSH" button - just a regular sshd process on a regular *nix box. A more common option might be a button in a VPS provider's control panel, to quickly launch an SSH session to an instance (particularly if the hostnames are reasonably long and hard to type)

> Basically, since the browser can understand the rest of the HTML/HTTP on the trusted page along with the ssh://name?fingerprint link, I think it makes sense to leverage it when wanting to open a connection to the same name, rather requiring the name to be a domain name and using DNS to get those values.

That implies a heavy tie between the browser and SSH. Technically, if you wanted to do this, one could write a small script/app that gets registered as the default ssh:// handler, parses out the FP and adds it to the known_hosts file before calling the regular ssh. But for obvious reasons this is dangerous without knowing the source of the FP. Which brings us back to a browser having to understand and integrate with SSH.

Im sorry but I just don't see the problem you have with using SSHFP records for this, or the specific desire to integrate with a browser and HTML of all things.

At best, you'd still have to have your fingerprints in both places (DNS and markup) to support a) connections initiated manually and b) browser/ssh combinations that don't support manually specifying a fingerprint but do support SSHFP records (which currently, is all browsers and any reasonably recent version of OpenSSH)

Frankly a better endeavour than getting a browser to understand SSH, would be to a) get more people using VerifyHostKeyDNS and SSHFP records and b) get more people using DNSSEC. Those are actual, real world things that are simply lacking adoption/usage, but do very much work.