# Accessing Jupyter on a cloud GPU through an SSH tunnel

Access Jupyter on a cloud GPU through a loopback SSH tunnel while preserving notebook authentication and distinguishing local from remote ports.

Author: Retrivium team
Updated: 2026-11-01
Canonical URL: https://retrivium.ai/journal/cloud-gpu-jupyter-ssh-tunnel/
Language: en

For personal Jupyter work on a cloud GPU VM, leave the service on localhost and use an SSH tunnel. The browser connects to a loopback port on your computer while SSH forwards traffic inside the VM. This workflow does not require publishing the notebook HTTP port to the internet.

## Verify Jupyter and ordinary SSH first

Check the running Jupyter process and its expected listener inside the VM, then establish a normal SSH login. A provider-specific limited proxy may not support the required forwarding, so verify the selected transport rather than assuming all SSH-labelled paths are equivalent.

Use the actual user, host and external SSH port for the current resource. Do not copy another provider's parameters. A live notebook process and a working terminal route are separate acceptance checks.

## Distinguish local and remote loopback

The source forwarding example is:

```text
ssh -N -L 127.0.0.1:8899:127.0.0.1:8888 USER@HOST -p SSH_PORT -i PRIVATE_KEY
```

The left address is on the laptop; the right destination is interpreted from the SSH-server side. Substitute current parameters and open `http://127.0.0.1:8899` locally. Port `8899` is illustrative and must be free on your computer.

Keep the local listener on loopback if only this computer needs access. The private key stays in its local file. Do not copy it into the notebook or use an unrestricted local listener without a deliberate access requirement.

## Preserve application authentication

SSH encrypts the route but does not manage notebook users. Retain Jupyter's expected token or password and keep secret-bearing URLs out of reports. Verify that the intended user is authenticated after the page opens.

A personal Jupyter Server is not a complete multi-user solution. Its documentation points to JupyterHub for that role. Shared kernels and files can conflict even when the network connection itself is protected correctly.

## Diagnose the route in order

| Symptom | Next check |
| --- | --- |
| SSH login fails | User, key, route and external port |
| Login works, page does not | Jupyter process and tunnel destination |
| Local port is occupied | Another available laptop port |
| Page asks for a token | Notebook authentication |

After a network interruption, check both the remote process and local tunnel. A calculation's survival depends on how it was launched, not only on an open browser tab. Close the tunnel after use, save files to the intended storage and keep a secret-free reconnection recipe for the next session.

## Turn the check into a practical next step

A tunnel provides transport to a local notebook service. It does not replace Jupyter authentication or turn a personal server into a multi-user platform.

For the documented details, consult the [primary documentation](https://jupyter-server.readthedocs.io/en/latest/operators/public-server.html); [configuration reference](https://man.openbsd.org/ssh). Continue with [runpod private port forward](/journal/runpod-private-port-forward/) and [selectel gpu jupyter notebook access](/journal/selectel-gpu-jupyter-notebook-access/).