notebook: tip of the day -- running a server on a remote machine using ssh tunneling
William Stein
If you want to run the Sage notebook on a remote machine where Sage is
installed, and you can only ssh to the remote machine, but not open
outside ports, do:
ssh -L 5900:localhost:8000 remote.computer.edu /path/to/sage -notebook port=8000
Then open
on your computer.
The above should be very secure even with secure=False, since it all
goes through ssh. Only you can connect to the server. An advantage
is that it works even if there is a firewall on remote.computer.edu
that prevents opening outgoing connections. E.g., I used this today
to run a notebook server on a computer at UGA.
You'll need to login, so be sure to set a password on the remote
server, e.g., by typing
sage: notebook(reset=True).
-- William
P.S. Nils Bruin originally contributed a version of this very tip on a
sage list a few years ago.
--
William Stein
Associate Professor of Mathematics
University of Washington
http://wstein.org
Minh Nguyen
On Mon, Sep 14, 2009 at 6:18 AM, William Stein <wst...@gmail.com> wrote:
>
> Hi,
>
> If you want to run the Sage notebook on a remote machine where Sage is
> installed, and you can only ssh to the remote machine, but not open
> outside ports, do:
>
> ssh -L 5900:localhost:8000 remote.computer.edu /path/to/sage -notebook port=8000
>
> Then open
>
> http://localhost:5900
>
> on your computer.
This tip should be fleshed out and included somewhere in the release
management wiki page at
http://wiki.sagemath.org/release
I feel ashamed to admit that I'm not able to do this fleshing out work
as I hardly use the notebook.
Before releasing a stable version of Sage, a release manager needs to
ensure that Sage compiles (on the various supported platforms) and
also that Sage starts from the command line. Equally important is that
one needs to ensure that the Sage notebook also can be loaded. The
Internet provides a dirt cheap communication medium for open source
projects. However, downloading a 200 MB tarball to one's local
computer for each pre-release can quickly eats into one's monthly
Internet quota. I have no problem with upgrading. But I don't want to
rule out the possibility that someone would download the full source
tarball and compile it.
--
Regards
Minh Van Nguyen
William Stein
>
> Hi William,
>
> On Mon, Sep 14, 2009 at 6:18 AM, William Stein <wst...@gmail.com> wrote:
>>
>> Hi,
>>
>> If you want to run the Sage notebook on a remote machine where Sage is
>> installed, and you can only ssh to the remote machine, but not open
>> outside ports, do:
>>
>> ssh -L 5900:localhost:8000 remote.computer.edu /path/to/sage -notebook port=8000
>>
>> Then open
>>
>> http://localhost:5900
>>
>> on your computer.
>
> This tip should be fleshed out and included somewhere in the release
> management wiki page at
>
> http://wiki.sagemath.org/release
>
> I feel ashamed to admit that I'm not able to do this fleshing out work
> as I hardly use the notebook.
I've put this on the todo list for adding to the output of "sage:
notebook?". I think it also belongs there. But you raise a very good
point that adding this to the release management page will make it
easy for people to use.
What about the tip needs to be fleshed out?
> Before releasing a stable version of Sage, a release manager needs to
> ensure that Sage compiles (on the various supported platforms) and
> also that Sage starts from the command line. Equally important is that
> one needs to ensure that the Sage notebook also can be loaded.
Better would be automated testing of the notebook using Selenium or
something, so "make test" would verify that the notebook server works.
> The
> Internet provides a dirt cheap communication medium for open source
> projects. However, downloading a 200 MB tarball to one's local
> computer for each pre-release can quickly eats into one's monthly
> Internet quota. I have no problem with upgrading. But I don't want to
> rule out the possibility that someone would download the full source
> tarball and compile it.
If you're using sage.math to run Sage, then you don't have to use an
ssh tunnel. Just do:
sage: notebook(address='sage.math.washington.edu', secure=True)
and you're good to go. That's it.
William
Nils Bruin
> > This tip should be fleshed out and included somewhere in the release
> > management wiki page at
>
> >http://wiki.sagemath.org/release
>
> > I feel ashamed to admit that I'm not able to do this fleshing out work
> > as I hardly use the notebook.
>
> I've put this on the todo list for adding to the output of "sage:
> notebook?". I think it also belongs there. But you raise a very good
> point that adding this to the release management page will make it
> easy for people to use.
>
> What about the tip needs to be fleshed out?
leads to lower security than people might initially think they will
have:
- You are still running the notebook, so anybody logged in locally on
the machine can try to connect to the notebook process. This is always
the case, of course, but if you have the notebook running on a remote
machine I expect it to be the norm that the machine is a multi-user
machine.
- When you are setting up a tunnel this way, it's more difficult to
open the browser on the right port.
If you can afford to forward the same port number, the following gives
a slightly smoother experience if the user already has firefox open:
ssh -X -L 8000:localhost:8000 remote-machine.university.com "sage -
notebook"
The X-forwarding means that the firefox -remote will actually connect
(via X?) with the already-connected firefox process on the desktop
computer and instruct that browser to open the appropriate port. If
the login certificate in the URL is one-time-only, there is only a
very short window for abuse. Of course, should you close your browser,
your connection is gone. Should the notebook process listen to the
console for a signal to fire a "reopen browser" process?