Running the proxy without SSL

[Norman Gray]

Greetings.

It's not clear how I configure JuypterHub to run with plain HTTP rather
than HTTPS, or how to have it listen on two separate interfaces.

I plan to terminate SSL in an nginx reverse proxy, so I want JupyterHub
to to run without SSL. I can't work out quite how to do that: that is,
I might be reporting a documentation issue here, rather than a
functionality one.

The page
<http://jupyterhub.readthedocs.io/en/latest/getting-started/security-basics.html>
implies, but doesn't quite state, that if one simply omits
c.JupyterHub.ssl_key and .ssl_cert, then the server will run
successfully without SSL. If that is the case, then that page could
usefully be more explicit about that. (I could of course just try this
in a test server and see what happens, but partly for the doc-bug, and
partly for the reason below, that wouldn't quite answer my question).

The section 'If SSL termination happens outside of the Hub' makes it
clear that this (no SSL) is a possible configuration, but isn't clear
how to get to that.

My situation is that I have a production JupyterHub running with SSL on
port 8000, but I want to have this live instead behind an nginx proxy on
the same machine. Thus I want to deprecate the port-8000 service in
favour of the proxied one, but not yet remove it. Thus I'd like to have
the JuypterHub running on port 8000 with SSL, and _also_ listening on
another port, only on localhost, without SSL.

The parameters c.JupyterHub.ip and .port take only single values, rather
than a list, so I'm guessing that this _isn't_ a supported
configuration, but I can't see anywhere in the docs that makes that
explicit (but I might just be missing the right instructions). In that
case, I might be better off having two JupyterHub instances running,
with different configs.

Best wishes,

Norman


--
Norman Gray : https://nxg.me.uk

[Roland Weber]

Afaik, listening on two different ports is not possible without changing code.

You could also solve your problem by keeping JupyterHub on the deprecated SSL port, and encrypting the connection between the SSL-terminating proxy and JupyterHub.

I'm sure that pull requests to improve the documentation will be happily accepted :-)

cheers,

  Roland

[Norman Gray]

Roland, hello.

On 22 Mar 2018, at 8:22, Roland Weber wrote:

> Afaik, listening on two different ports is not possible without
> changing
> code.

Righto -- thanks for confirming.

> You could also solve your problem by keeping JupyterHub on the
> deprecated
> SSL port, and encrypting the connection between the SSL-terminating
> proxy
> and JupyterHub.

Yes -- I'm going to run two servers, an exposed SSL one and a
reverse-proxied non-SSL one.

Are they likely to fight with one another, do you think? I can't think
of a reason why they would, but I could be lacking imagination here.

> I'm sure that pull requests to improve the documentation will be
> happily
> accepted :-)

I've added an issue
<https://github.com/jupyterhub/jupyterhub/issues/1747> which includes
some suggested text.

Thanks for your help. Best wishes,

[Michael Milligan]

Hi Norman -

You are correct that Jupyterhub will serve without SSL simply by not providing the SSL keys. There used to be an explicit "--no-ssl" flag but that was deprecated with the 0.7 release.

My suspicion is that this is going to be more finicky than you would like. Presumably you want users to be able to connect to the service using either endpoint. The simplest approach would be to run two fully parallel Jupyterhub stacks, but in that case your users would get two independent sessions if they connected through both endpoints. Maybe that is acceptable for your use case.

If not, you thus need to ensure that both Hub/Proxy pairs know about sessions and routes modified by the other. You can do this by pointing them at a common database backend, but I don't think this has been extensively tested and there may be corner cases where one Hub fails to query the DB at the right time. Certainly you will want to use a RDBMS server backend, since the default sqlite implementation is not safe for parallel access.

Alternately, and possibly more robustly, you could subclass the Proxy interface to make a single Hub drive two copies of the Proxy component.
https://jupyterhub.readthedocs.io/en/latest/reference/proxy.html

Personally, I would just run a single Jupyterhub stack (without SSL) behind nginx, and also have nginx or the Proxy (see "--redirect-port" at https://github.com/jupyterhub/configurable-http-proxy) serve a redirect from port 8000 to the nginx endpoint.

Regards,

Michael

--
You received this message because you are subscribed to the Google Groups "Project Jupyter" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jupyter+unsubscribe@googlegroups.com.
To post to this group, send email to jup...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jupyter/2F6AB0DA-4FA4-49B9-A202-231700E5090D%40gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Michael Milligan, Ph.D.         | Supercomputing Institute
Assistant Director for          | University of Minnesota
   Application Development      | mill...@umn.edu
www.msi.umn.edu/staff/milligan  | Phone: 612-624-8857

[Norman Gray]

Michael, hello.

On 22 Mar 2018, at 18:41, Michael Milligan wrote:

> My suspicion is that this is going to be more finicky than you would
> like.
>

> [snip]

Hmm: it does sound like it, from what you say.

I think, on reflection, that although it would be nice to have the two
services running in parallel, it's probably not urgent enough to warrant
the extra complication, and I'll simply change the config after the end
of the semester. People can live with an ugly URL for a couple more
months!

> Personally, I would just run a single Jupyterhub stack (without SSL)
> behind
> nginx, and also have nginx or the Proxy (see "--redirect-port" at
> https://github.com/jupyterhub/configurable-http-proxy) serve a
> redirect
> from port 8000 to the nginx endpoint.

That's pretty much my plan, with nginx (my first late-to-the-party
experience with nginx, which is suddenly My New Favourite Webserver),
and I've got that working on a test server. That was surprisingly
painless. Thanks for confirming that there are no obvious bear-traps
with this setup.