In this article
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 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:
ssh -N -L 127.0.0.1:8899:127.0.0.1:8888 USER@HOST -p SSH_PORT -i PRIVATE_KEYThe 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; configuration reference. Continue with runpod private port forward and selectel gpu jupyter notebook access.