On Friday, May 25, 2018 at 1:24:39 PM UTC-7, Volker Braun wrote: > > On Friday, May 25, 2018 at 7:02:19 PM UTC+2, Nils Bruin wrote: >> >> Since your approach requires the device to run ssh, a much more portable >> option is to run the jupyter server on the remote machine as well >> (listening on localhost) and use ssh to forward the relevant port so that a >> local browser can connect to it. >> > > If only browsers had a cryptographically secure way of transferring web > pages ;-) >
True, but in terms of attack service there is something to say for this approach. Since you let ssh take care of the identification and a big part of the authentication check, you're limiting the level to which jupyter has to do this securely. Since you're only exposing jupyter on localhost: ports, you only have to make sure that the local users each use their own port and are careful with their jupyter tokens or set a somewhat decent password to limit access to their jupyter server. It's a lot easier sell than letting jupyter(hub?) handle logins using regular usercredentials and then serve the respective homedirs and privileges on an internet-facing port. I can sell the localhost-with-ssh tunnelling to a sysadmin, but setting up a multi-user jupyter would draw frowns. A deployment with docker images would require even more commitment of sysadmin time and hardware. The advantage of ssh tunnelling is that you can make it work on a vanilla setup, with sage installed as a normal application (or even compiled and run by a user). -- You received this message because you are subscribed to the Google Groups "sage-support" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-support+unsubscr...@googlegroups.com. To post to this group, send email to sage-support@googlegroups.com. Visit this group at https://groups.google.com/group/sage-support. For more options, visit https://groups.google.com/d/optout.
