4 ms·

No need for custom url formats. Keep it really simple: Use a <link rel="ssh"> and rely on browsers to prompt us to "log in with ssh". IF there's no public key

by geocar 12y ago

No need for custom url formats. Keep it really simple: Use a <link rel="ssh"> and rely on browsers to prompt us to "log in with ssh". IF there's no public key, the browser could offer to run ssh-keygen for the user and save the results in the user's keychain. If we use switcher[1], we can even put ssh and https on the same hostname and on the same point. This would be a recommended configuration since it would get through most proxies. [1]: https://github.com/jamescun/switcher https://github.com/jamescun/switcher

stephenr 12y ago
The demo doesn't work for me - when I load the echo'd URL it shows up with "log out" on the left side but once the globe appears I get just "sign in with SSH to place a pin" again. However, the correct way to do this is the way browsers link to external protocols already: <a href="ssh://mars.vtllf.org">Open SSH connection</a> This is no different than a mailto: link, a skype: button, an ftp:// link, or any other link in a webpage that uses a protocol other than HTTP/HTTPS. Frankly, I don't want my browser talking to SSH servers. Because that means it has access to my SSH keys. If you don't think its a problem for your browser (that thing that runs javascript from anywhere on the planet) to have access to your SSH keys, the point of my comment will no doubt be missed. A browser should do one thing, and do it well: browse pages. Once you start adding SSH clients, RDP clients, etc, you are simply inviting security holes, and arguably missing the whole point of local apps.
nothrabannosir 12y ago
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.

by geocar 12y ago

stephenr 12y ago

The demo doesn't work for me - when I load the echo'd URL it shows up with "log out" on the left side but once the globe appears I get just "sign in with SSH to place a pin" again. However, the correct way to do this is the way browsers link to external protocols already: <a href="ssh://mars.vtllf.org">Open SSH connection</a> This is no different than a mailto: link, a skype: button, an ftp:// link, or any other link in a webpage that uses a protocol other than HTTP/HTTPS. Frankly, I don't want my browser talking to SSH servers. Because that means it has access to my SSH keys. If you don't think its a problem for your browser (that thing that runs javascript from anywhere on the planet) to have access to your SSH keys, the point of my comment will no doubt be missed. A browser should do one thing, and do it well: browse pages. Once you start adding SSH clients, RDP clients, etc, you are simply inviting security holes, and arguably missing the whole point of local apps.

nothrabannosir 12y ago

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.