# Jupyter на облачном GPU через SSH-туннель

Как открыть Jupyter на облачной GPU VM через SSH: localhost сервера, локальный порт, ключи, токен notebook и проверка туннеля без публикации интерфейса.

Автор: Команда Retrivium
Обновлено: 2026-11-01
Канонический URL: https://retrivium.ai/ru/journal/cloud-gpu-jupyter-ssh-tunnel/
Language: ru

Для личной работы с Jupyter на облачной GPU VM можно оставить сервер на localhost и открыть его через SSH-туннель. Браузер подключается к локальному порту вашего компьютера, а SSH пересылает соединение внутрь VM. Публично открывать HTTP-порт notebook для такого сценария не требуется.

## Проверьте сервер и доступ SSH

[Документация Jupyter Server](https://jupyter-server.readthedocs.io/en/latest/operators/public-server.html) описывает локальный запуск и требования защиты. Сначала убедитесь, что Jupyter действительно запущен на ожидаемом адресе и порту внутри VM. Затем проверьте обычный SSH-вход с вашей машины.

Если облачная площадка использует ограниченный прокси SSH, отдельно выясните поддержку перенаправления. Эта инструкция предполагает полноценный разрешённый SSH-путь. Сведения о пользователе, адресе и внешнем SSH-порте берут из текущей конфигурации VM, а не из примера другого провайдера.

## Различайте локальный и удалённый адрес

[Руководство OpenSSH](https://man.openbsd.org/ssh) описывает локальное перенаправление через `-L`. Учебная схема для Jupyter на порту `8888` выглядит следующим образом:

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

Левый адрес относится к ноутбуку, правый — к стороне SSH-сервера. После подстановки собственных параметров браузер открывает `http://127.0.0.1:8899`. Порт `8899` выбран для примера; он должен быть свободен на локальной машине.

Привязка локального порта к loopback ограничивает его доступность этим компьютером. Не меняйте её на все интерфейсы без отдельной причины. Приватный ключ остаётся локальным файлом и не передаётся в веб-форму notebook.

## Сохраните аутентификацию Jupyter

Туннель шифрует транспорт, но не управляет пользователями Jupyter. Оставьте предусмотренную аутентификацию токеном или паролем и не публикуйте секретную ссылку в общем отчёте. Если интерфейс открылся, проверьте, что доступ получает именно нужный человек.

Обычный личный Jupyter Server не является полноценным решением многопользовательской работы. Документация предлагает JupyterHub для соответствующего сценария. Совместное использование одного ядра и одних файлов может приводить к конфликтам, даже когда сетевое соединение защищено правильно.

## Пример диагностики пустой страницы

SSH входит успешно, но notebook не открывается. Сначала проверьте работу Jupyter внутри VM, затем свободный локальный порт и живой процесс туннеля. Если соединение есть, но требуется токен, это уже этап авторизации приложения, а не ошибка SSH-ключа.

| Симптом | Следующая проверка |
| --- | --- |
| Не входит SSH | Пользователь, ключ, маршрут и порт |
| SSH работает, страницы нет | Процесс Jupyter и адрес назначения |
| Локальный порт занят | Другой свободный порт ноутбука |
| Страница просит токен | Аутентификация notebook |

Меняйте один параметр за попытку, сохраняя точный результат. Это позволяет избежать случайного открытия лишних внешних портов.

После разрыва сети проверьте оба процесса: жив ли Jupyter на сервере и действует ли локальное перенаправление. Продолжающийся расчёт может пережить закрытие браузера, но это зависит от организации запуска. Не определяйте судьбу задачи исключительно по доступности открытой вкладки notebook.

## Завершите сессию и сохраните файлы

Закройте туннель после работы и проверьте сохранение notebook на нужном диске. Состояние ядра и файлы имеют разный жизненный цикл. Подготовьте короткую инструкцию повторного подключения без секретов.

Для примеров площадки прочитайте [туннель Runpod](/ru/journal/runpod-private-port-forward/) и [Jupyter Selectel](/ru/journal/selectel-gpu-jupyter-notebook-access/).