Single User Mode

[mlucool]

trafficstars

Hi,

I'd like to run an enterprise gateway as the only user. There are a few reasons why one would want this including including no need for user impersonation and no noisy neighbors. The gateway is still very useful and lets me launch in other containers outside of the one my JupyterLab is running. This then becomes a direct replacement for remote_ikernel.

To make this work, two features would be very helpful:

• [x] Support for SSH with gss - Merged PR #950
• [ ] Support for unix sockets to connect to the gateway (and thus avoid thinking about a host of security concerns)

2 can be done with below, but I'm not sure how we'd want to allow users to opt into this.

--- a/enterprise_gateway/services/processproxies/processproxy.py
+++ b/enterprise_gateway/services/processproxies/processproxy.py
@@ -340,12 +341,13 @@ class BaseProcessProxyABC(with_metaclass(abc.ABCMeta, object)):
         try:
             ssh = paramiko.SSHClient()
             ssh.load_system_host_keys()
-            ssh.set_missing_host_key_policy(paramiko.RejectPolicy())
+            ssh.set_missing_host_key_policy(paramiko.AutoAddPolicy())
             host_ip = gethostbyname(host)
             if remote_pwd:
                 ssh.connect(host_ip, port=ssh_port, username=remote_user, password=remote_pwd)
             else:
-                ssh.connect(host_ip, port=ssh_port, username=remote_user)
+                ssh.connect(host_ip, port=ssh_port, gss_auth=True)
         except Exception as e:
             http_status_code = 500
             current_host = gethostbyname(gethostname())

[kevin-bates]

This seems like a reasonable request. Unfortunately, I believe this would have to come in the form of a contribution since I know I don't have the bandwidth (or expertise) to tackle this.

From an opt-in perspective, I think this would be minimally accomplished using an env-switch - after which we could look into tieing to a configurable trait (if necessary).

Is this something you'd be interested in doing?

Support for unix sockets to connect to the gateway

Would this be similar to what was done in Notebook?

[mlucool]

Is this something you'd be interested in doing?

We'd be happy to contribute this!

Would this be similar to what was done in Notebook?

Yes

[kevin-bates]

Excellent! Thank you Marc (et al)!

I'm curious, does the --gateway-url=http://gateway-host:port syntax in the notebook/jupyter_server CLI/config change at all?

[Carreau]

Support for unix sockets to connect to the gateway

Would this be similar to what was done in Notebook?

I've looked a bit into what is needed to make this work:

With tornado :

• From what I can tell, this seem to not be too hard for normal http requests on the server (gateway) side,
• Problem : It seem like tornado is fairly unhappy with unix-socket for anything websocket related. At least on the websocket client-side it seem to be a big no-no, as anything websocket related will no accept resolver and have many checks about protocols.

Adding a dependency:

• websocket depende claim to support client with unix-socket , but has not seen a release since Nov 2019, author and library seem active on github though.
• websocket-clienthave the same claim, and similar activity but had a more recent release. It does not claim to be stable though.

I believe instead of trying to do websocket over unix socket, another possibility is to write a version of ZMQChannelsHandler for the gateway but that read from unix-socket, and a version of GatewayWebSocketClient (for jupyter_server) that write to unix-sockets skipping most of the websocket-ish specificities, like protocol upgrade, compression etc...

We could also try to make a fake-websocket-like mock class that only support the features we need (like none of the compression; encryption and version upgrade); that might work but I'm unsure how that will interact with tornado.

I also know that ipykernel can use ipc between client and kernel; so there might be some possibilities there by actually using ZMQ/ipc between server and gateway;

I might be missing something especially on the tornado front; in which case I welcome pointers.

[kevin-bates]

Thank you for your insights @Carreau. I'm going to have to defer to the others on this. @mlucool - do you have any thoughts on Matthias's comment?

[Carreau]

See #950 for the ssh/gss part, though I'm looking at a system where I can test that – or deploy one locally between VMS if not.

I've talked with @mlucool via private channels, and I think we will hold off for now on using a unix socket as it would be a major endeavour.