ohk6cg
Last Updated: August 19, 2017
·
73.98K
· cheglastgnat
Fa1a7113e7e1ee90e0bfd383c6d85af4

Remote Access to IPython Notebooks via SSH

Scenario: On your local computer, you want to open and manipulate an IPython notebook running on a remote computer. We will do this by opening an SSH tunnel. This tunnel will forward the port used by the remotely running IPython instance to a port on the local machine, where it can be accessed in a browser just like a locally running IPython instance.


On the remote machine, start the IPython notebooks server:

remote_user@remote_host$ ipython notebook --no-browser --port=8889

Usually IPython opens a browser to display the available notebooks, but we do not need that so we use the option --no-browser. We also change the port to 8889, for no other reason than to show how this is done.

On the local machine, start an SSH tunnel:

local_user@local_host$ ssh -N -f -L localhost:8888:localhost:8889 remote_user@remote_host

The first option -N tells SSH that no remote commands will be executed, and is useful for port forwarding. The second option -f has the effect that SSH will go to background, so the local tunnel-enabling terminal remains usable. The last option -L lists the port forwarding configuration (remote port 8889 to local port 8888).

Now open your browser on the local machine and type in the address bar

localhost:8888

which displays your remotely running IPython notebook server.


To close the SSH tunnel on the local machine, look for the process and kill it manually:

local_user@local_host$ ps aux | grep localhost:8889
local_user 18418  0.0  0.0  41488   684 ?        Ss   17:27   0:00 ssh -N -f -L localhost:8888:localhost:8889 remote_user@remote_host
local_user 18424  0.0  0.0  11572   932 pts/6    S+   17:27   0:00 grep localhost:8889

local_user@local_host$ kill -15 18418

Alternatively, you can start the tunnel without the -f option. The process will then remain in the foreground and can be killed with ctrl-c.

On the remote machine, kill the IPython server with ctrl-c ctrl-c.

Say Thanks
Respond

20 Responses
Add your response

17974
None

This does not work when I have to use SSH to get to the remote machine to start the IPython notebooks server, right?

over 1 year ago ·
17986
Fa1a7113e7e1ee90e0bfd383c6d85af4

That should work as well, yes. Is there a problem with the first step?

over 1 year ago ·
17988
None

Oh, I am sorry. The first time I tried this, I couldn't start the second SSH tunnel on my local machine, and from the error I assumed that it's not possible. I thought if I have to open a "standard" SSH tunnel to start IPython notebooks server on the remote machine I would not be able to open a second one setting the port forwarding.
I was wrong, though, since it worked perfectly fine this time.

over 1 year ago ·
17989
Fa1a7113e7e1ee90e0bfd383c6d85af4

Ah, good to know it works! :)

By the way, you don't have to keep both ssh connections open. I usually use screen or tmux on the remote server to keep my remote session alive. This way, I only have to login once to start the IPython notebook server, then I can detach the session and logout.

over 1 year ago ·
17991
None

I haven't heard of any of these before... but it seems we have screen on the server already! Thanks for the tip, I'll try that right away. :-)

over 1 year ago ·
21441
0 q6hj9g7pt e 9yj1nti698jasgy nzz1n3qq9tyatkegwp7pzhrzz3hh fodzxm0zlgfj6ghlz b

Onn the browser I got "channel 2: open failed: connect failed: Connection refused" It works tunneling ssh -N -f -L localhost:8888:127.0.0.1:8889 Juhuuuu!!!

over 1 year ago ·
21455
Fa1a7113e7e1ee90e0bfd383c6d85af4

Hi ilciavo, thanks for your comment! Perhaps there is a security setting on your machine which blocks that specific port of "localhost"?

over 1 year ago ·
22559
None

I am getting the same error as ilviavo, but using the address doesn't work for me. I also get:
bind: Address already in use
channelsetupfwd_listener: cannot listen to port: 8888
Could not request local forwarding.

But searching for ps aux | grep localhost:8889 or ps aux | grep localhost:8888 doesn't show anything.

Any suggestions?

over 1 year ago ·
22562
Fa1a7113e7e1ee90e0bfd383c6d85af4

Hi Nic,
sounds like port 8888 might already be in use on your machine. If that's the case, it should show in the output of
"netstat -tulpn | grep 8888" (might need root)
You can try any other port above 1024 :)

over 1 year ago ·
23323
None

Great tutorial! I want to add a tip for enabling display of remote figures (I got a DISPLAY error when the remote server executing my ipython notebook code didn't have anywhere to put Xwindows)

Although you can use XPRA to forward the entire browser window remotely, it's slow. Combining xpra for remote display of xwindows (e.g., matplotlib or mayavi figures), you can combine the advice from here (https://wiki.archlinux.org/index.php/Xpra)

remote@remote$ xpra start :100

remote@remote$ DISPLAY:=100 screen

remote@remote$ ipython notebook --no-browser --port=8889

local@local$ ssh -N -f -L localhost:8888:localhost:8889 remoteuser@remotehost

And you'll see figures opened on your remote machine pop up in xpra windows on your local machine

over 1 year ago ·
23324
Fa1a7113e7e1ee90e0bfd383c6d85af4

Hi phareaux,

thanks for the (pro)tip! Usually inline figures are good enough for me, but this sounds great.

over 1 year ago ·
23378
None

Hi cheglastgnat,

I try to use inline figures as well, but unfortunately mayavi inlining in ipython notebook isn't (yet) well supported (screenshots, no interactivity). It doesn't seem to actually forward the interactive scenes (empty windows), but it doesn't give me errors.

over 1 year ago ·
27464

If I need the ipython notebook process continues to run even if the ssh disconnect, simply remove the -f command? So I can access the process until new connection just reconnect ssh with the same port of the process?
I will make a parallel programming processing and machine learning, the training will last about 15 days and must monitor the process, would do via shell normally, but the idea of using the ipython notebook is extremely more satisfactory ...

over 1 year ago ·
27470
None

As an amendment to my previous comment (about xpra), I think there's a simpler way to do X forwarding of a window outside of the ipython notebook environment. Also, the way I tried doing kept failing for awhile, so I got the below to work (also, there's a typo in the old DISPLAY=:Z string)

  1. create vnc server on remote host, which will allocate a new X display if necessary and tell you it as an integer: <outputfromvncserver> remote@remote$ vncserver
  2. either a. export the resulting display via remote@remote$ export DISPLAY=:<outputfromvncserver> and then start ipython notebook with command recommended by article (with same environment!) or 2b.
  3. start ipython notebook
    inside the notebook

    import os
    os.environ['DISPLAY'] = '<outputfromvncserver>'

  4. now you can use a vncviewer with something like
    local@local$ vncviewer remote@remote:<outputfromvncserver>

and you'll see a remote desktop appear, along with any mayavi figures (or other out-of-notebook X windows?) you might be using

over 1 year ago ·
28219

Thanks so much

10 months ago ·
28284

If you're on a secure network just pass -ip=* and you can connect it from all machines without SSH tunneling!

10 months ago ·
28498

Nice tutorial.. Was precisely looking for this! :)

@phareaux: regarding X forwarding, is there a reason why X forwarding over ssh wouldn't work?

7 months ago ·
28621

The kernel keeps disconnecting when I'm away from my seat. Sometimes I need the GPU running for hours to reach the end result; does anyone have solutions to this?

6 months ago ·
28636

I'm trying to use this protocol, but when I try to create a new Python notebook in my browser the Jupyter notebook dies and no new notebook is created. No useful error is outputted either. Has anyone else encountered this problem?

6 months ago ·
28644

I think that using same port on local and remote will be better for clarity, it is possible https://maketips.net/tip/148/forward-remote-port-to-local-using-ssh

6 months ago ·
Filed Under