0

I want to run a jupyter notebook from SSH to remote server node. Steps:

  1. ssh user@remote.server
  2. jupyter notebook --no-browser --port=8887

Steps on my computer:

  1. ssh -N -L localhost:8888:localhost:8887 user@remote.server
  2. run localhost:8888

This works fine. However I want to run this on node1 that is inside user@remote.server, because node1 contains a GPU.

Steps I have done are similar except for this: ssh -N -L localhost:8888:localhost:8887 user@remote.server "ssh node1"

But this does not work: "channel 2: open failed: connect failed: Connection refused"

Edit: /etc/hosts: enter image description here

Solution after several attempts, following the answer of @ajz34:

  1. On node1: jupyter notebook --no-browser --port=8886 --ip=127.0.0.1
  2. On server: ssh -N -L 8887:127.0.0.1:8886 node1
  3. On local: ssh -N -L 8888:127.0.0.1:8887 user@xxx.xxx.xxx.xxx
CasellaJr
  • 378
  • 2
  • 11
  • 26

1 Answers1

2

I think a possible simple solution could be adding an intermediate ssh connection.

Given your workflow is computer -> server (accessing node) -> node1 (computing node), then

  • From user@remote.node1, execute

    jupyter notebook --no-browser --port=8886

  • From user@remote.server, execute

    ssh -N -L localhost:8887:localhost:8886 user@remote.node1

  • From your computer, execute

    ssh -N -L localhost:8888:localhost:8887 user@remote.server

    Then run localhost:8888 on your computer browser.

From the resolution of @CasellaJr, perhaps for different servers, you may wish to explicitly change localhost to 127.0.0.1 or [::1] or other addresses that may work.

ajz34
  • 113
  • 7
  • In case the computing node (node1) could not assign requested localhost address, adding `--ip=127.0.0.1` after `jupyter notebook ...` could avoid this problem. I've just encountered this problem on my HPC environment. – ajz34 Dec 07 '21 at 11:15
  • I also found https://stackoverflow.com/a/60431456/7740992. If computing node is not accessible by ssh but could by LSF, then an LSF script is required. – ajz34 Dec 07 '21 at 11:21
  • I continue to have this error: channel 2: open failed: connect failed: Connection refused – CasellaJr Dec 07 '21 at 16:19
  • To be sure, I have done this: in the conda env of my node1: `jupyter notebook --no-browser --port=8886 --ip=127.0.0.1` then in my server: `ssh -N -L localhost:8887:localhost:8886 user@ip node1` and on my local PC: `ssh -N -L localhost:8888:localhost:8887 user@ip` – CasellaJr Dec 07 '21 at 16:24
  • I think that I have followed your advice but it does not work. Note that the error `channel 2: open failed: connect failed: Connection refused` appears on the terminal in which I write `ssh -N -L localhost:8887:localhost:8886 user@ip node1` – CasellaJr Dec 07 '21 at 16:25
  • @CasellaJr I'd admit the error of connection refused is not occurring on my workaround. Perhaps this is rather an ssh error. I'm not sure whether following discussion helps. https://serverfault.com/questions/489192/ssh-tunnel-refusing-connections-with-channel-2-open-failed – ajz34 Dec 09 '21 at 04:26
  • @CasellaJr I then encountered this `channel 2` and `channel 3` in a strange way =,= If three bash commands are not executed sequentially (node1->server->PC), then this error could occur. – ajz34 Dec 09 '21 at 04:42
  • in /etc/hosts of server (and also node1) I have the output in the image (I edited the original message with a picture) – CasellaJr Dec 09 '21 at 11:41
  • Maybe i have to substitute "localhost" with 127.0.0.1 when I am inside the server and substitute `--ip=xxx.xx.x.xxx` when I run the jupyter command inside the node1? – CasellaJr Dec 09 '21 at 11:42
  • @CasellaJr I'm not sure but in my workaround using "localhost" inside the server is okay >. – ajz34 Dec 09 '21 at 11:57
  • Maybe i will post the same question also on serverfault ;( – CasellaJr Dec 09 '21 at 13:26
  • OMG now is working. I will edit the original post with the code I have used, so you can edit your answer and I will accept it ;) – CasellaJr Dec 09 '21 at 13:31
  • Good to hear that a resolution has been found! Great ≥w≤ From your resolution, I guess perhaps explicitly changing localhost to ip address is better. – ajz34 Dec 10 '21 at 17:11