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.

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.