Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Signing in to websites with SSH

vtllf.org

Post reply on HN
Print view View original

151–160 of 169 posts

Re: Signing in to websites with SSH

#151

Post by stephenr »

pb2au wrote: post #148
stephenr wrote: post #147

Earlier quoted context omitted.

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.

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 i…

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

Re: Signing in to websites with SSH

#152

Post by tomjen3 »

scott_karana wrote: post #106
hughes wrote: post #101

This question might be hilariously naive... but why don't web browsers make signed requests, just as web servers make signed responses? If I create an account on a website, then associate a public key with my account, shouldn't the browser be able to sign each request with my key? The website then wouldn't ever even have to deal with cookies or sessions as long as I was logged in to my browser. Or better yet, if my k…

This idea is exactly what I've always wanted, too. As others point out, it would definitely have to be opt-in, or it would be a great way to track. (It would be nice to have ephemeral keys per-site, too, a la Bitcoin: why have a publically unified identity?)

That features has been in substantially every browser for years, I am pretty sure IE 5 had it.

The problem is that the UI for client side certificates is of-putting, inconsistent and terrible in every single browser (also people expect to be able to use your web service from more than one computer).

Re: Signing in to websites with SSH

#153

Post by Gurkenmaster »

ubertaco wrote: post #66
jasonkester wrote: post #31

"SSH is near-universally loved among developers." Really? Which developers? SSH is one of those things you get forced to deal with a couple times a year for some irritating task, and it involves firing up Putty, figuring out where you left your key file, trying to remember how to actually load that key file, and a bunch of following steps on some website just to get connected to what you were trying to connect to. It…

Yeah, the Windows-based alternatives (RDP, VNC, or even shudder something like GoToMyPC) are waaay better for quick dead-simple system administration. /s SSH works great for systems that didn't have to have networked multi-user support hacked in later in their lifecycle. Systems that let you actually get stuff done without having to paint a whole GUI environment to do it. I can automate running "git pull && mvn clean…

It's possible to forward an X server over ssh via putty to Xming on Windows.

Re: Signing in to websites with SSH

#154

Post by nothrabannosir »

stephenr wrote: post #144
pb2au wrote: post #143

Earlier quoted context omitted.

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.

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 tha…

Call it an amendment. I am neutral on the whole "connect to SSH through an HTML client", but I'll tell you what: the fingerprint is a necessary connection parameter, as much as the hostname or port. Not an afterthought.

Solve it however you like.

$ ssh --fingerprint ab:cd:...

or

ssh://user@hostname?ab:cd...

or

FINGERPRINT_VAR=ab:cd:... ssh somehost

or

what

ever.

One is ugly, the other is uglier. Fine. At least they're actually secure.

Guess: how many people actually check the full fingerprint before accepting it? On a good day, I remember the first four letters (2 bytes). Whenever I tell people, it's blank looks all around. What's a fingerprint?

And these are people who use SSH.

UI is important. UI matters. Good UI helps. UI UI UI UI UI.

The fingerprint is a required parameter for connection! Not just the hostname, also the fingerprint.

Sure, let the client cache it and automatically allow leaving it out on subsequent connects. But don't allow initial, fingerprintless connections. Never.

Implemented properly, this addresses the DNSSEC alternative. Do you have DNSSEC installed, do you trust it? Okay, get the key from there. Don't have it? And it isn't specified in the connection parameters? Woops, no connect. Impossible. Why? Because without a pre-supplied fingerprint, no SSH client should ever connect.

We don't need to debate DNSSEC here, the clients will speak. I know I'd be including the fingerprint in the connection parameters directly, but do as you please.

Make a get-fingerprint-insecurely tool, that just connects to a host and prints you what it thinks is the key. This allows people to still make insecure connections, but it's explicit. Make MITM and insecurity the cumbersome and explicit way. Not default.

This is such a frustrating, last-mile, almost-right-thus-wrong issue.

You're right in theory. In practice, unfortunately, people don't check the fingerprints. And the sad thing? We could do something to fix that.

Join the Fingerprints are a required connection parameter-movement.

PS: I think we're on the same side here. I don't go to sleep dreaming of SSH fingerprints: I'm just against allowing MITM by design. Of course, certificates, or any other means of ensuring the connection is not MITM'ed is just as good. Fingerprints as required connection parameters are just the easiest way to get that done, right now, today, in our way of working. But once everyone uses certificates properly: fine, forget about them. This non-MITM design needs to become part of everyone's understanding of SSH.

Re: Signing in to websites with SSH

#155

Post by pb2au »

stephenr wrote: post #151
pb2au wrote: post #148

Earlier quoted context omitted.

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 i…

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

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.

Re: Signing in to websites with SSH

#156

Post by stephenr »

pb2au wrote: post #155
stephenr wrote: post #151

Earlier quoted context omitted.

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

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 matt…

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

Re: Signing in to websites with SSH

#157

Post by pb2au »

stephenr wrote: post #156
pb2au wrote: post #155

Earlier quoted context omitted.

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 matt…

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

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.

Re: Signing in to websites with SSH

#158

Post by stephenr »

pb2au wrote: post #157
stephenr wrote: post #156

Earlier quoted context omitted.

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

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 t…

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

Re: Signing in to websites with SSH

#159

Post by stephenr »

nothrabannosir wrote: post #154
stephenr wrote: post #144

Earlier quoted context omitted.

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 tha…

Call it an amendment. I am neutral on the whole "connect to SSH through an HTML client", but I'll tell you what: the fingerprint is a necessary connection parameter, as much as the hostname or port. Not an afterthought. Solve it however you like. $ ssh --fingerprint ab:cd:... or ssh://user@hostname?ab:cd... or FINGERPRINT_VAR=ab:cd:... ssh somehost or what ever. One is ugly, the other is uglier. Fine. At least they'r…

I agree that blindly accepting fingerprints is a bad idea, but I still think this can be solved for the majority of use-cases, with largely existing options, and without forcing the UI to be worse for users (when setup correctly)

From my understanding (I haven't tried this in practice yet), setting both StrictHostKeyChecking and VerifyHostKeyDNS to 'yes' will give most of what you want - it won't prompt to accept random keys (that's the StrictHostKeyChecking=yes bit) but it will explicitly trust SSHFP records it finds in DNS (thats the VerifyHostKeyDNS=yes bit). Obviously, you need to make sure your SSH client is using a DNS resolver library that actually supports & checks DNSSEC secured records.

Obviously you could just enable StrictHostKeyChecking (without VerifyHostKeyDNS) and use a simple shell script wrapper for SSH to accept a FP and append it to the known_hosts file before calling true ssh.

'ssh-keyscan' is your 'get-fingerprint-insecurely' tool in a nutshell.

Re: Signing in to websites with SSH

#160

Post by pyre »

hamburglar wrote: post #130
tedunangst wrote: post #124

Earlier quoted context omitted.

'find_by_email' is what counts as a raw database query these days? I feel so old.

At my company, using an interactive shell on prod to invoke DB queries, even through the ORM, is basically considered a raw database query, and is strictly forbidden. It's untested code coming straight from your fallible fingers and manipulating the prod database. I don't see why this should be treated as any different than a raw db query. You can do some pretty powerfully destructive stuff with an ORM.

My previous company had "read-only" credentials to production.
Post reply on HN