Перейти к содержимому

SSH-подключения

External SSH подключает Gateway к конкретному удалённому хосту с учётными данными, настроенными администратором. Это не коннектор Git-репозитория, не управляемая нода Bastion и не замена регистрации демона. Для репозиториев используйте Git-хостинги, для постоянного управления через демон — ноды.

  1. Откройте раздел External SSH в Settings > Integrations.
  2. Укажите отображаемое имя, хост, порт и имя удалённого пользователя. Выдайте этому пользователю только необходимые для операции права ОС.
  3. Выберите пароль или генерацию SSH-ключа в Gateway. Новые подключения не принимают произвольный импорт приватных ключей. Установите сгенерированный публичный ключ для удалённого пользователя; если интерфейс предлагает подходящий существующий ключ, его можно использовать повторно.
  4. При необходимости выберите существующее подключение к промежуточному серверу и проверьте доступ через него.
  5. Получите отпечаток ключа хоста и сверьте его по независимому доверенному каналу перед подтверждением.
  6. Сохраните подключение и проверьте аутентификацию. При смене ключа хоста выясните причину, а не отключайте проверку.

Учётные данные хранятся зашифрованными. Пользователь SSH root и системный администратор Gateway относятся к разным системам авторизации: права на удалённом хосте не наследуются от роли пользователя Gateway.

Подготовка удалённого пользователя и публичного ключа

Заголовок раздела «Подготовка удалённого пользователя и публичного ключа»

У SSH нет прав API провайдера. Доступ определяется удалённым пользователем Unix, правами файлов и явно настроенным повышением привилегий.

  1. Убедитесь, что сервер Gateway достигает хоста и порта SSH (обычно 22) напрямую либо через настроенный промежуточный сервер.
  2. Сгенерируйте ключ в Gateway и скопируйте публичную часть. Не создавайте другой несвязанный ключ локально и не вставляйте приватный ключ в authorized_keys.
  3. Через доверенную консоль войдите под нужным удалённым пользователем. Подготовьте его каталог SSH:
Окно терминала
mkdir -p ~/.ssh
chmod 700 ~/.ssh
touch ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys
  1. Откройте ~/.ssh/authorized_keys редактором и добавьте публичный ключ одной строкой, сохранив существующие ключи. Файл и каталог должны принадлежать этому пользователю. Если редактируете от администратора, используйте домашний каталог целевого пользователя, а не администратора.
  2. Проверьте ключ сервера через консоль провайдера или другой независимо доверенный канал. Для ключа хоста Ed25519:
Окно терминала
ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub -E sha256
  1. Сравните SHA-256 отпечаток с предложенным Gateway ключом того же алгоритма. Значение, полученное только через непроверенное соединение, не является независимым подтверждением. Сохраните проверенный отпечаток и проверьте аутентификацию.
Сценарий Требования к удалённому пользователю
Вход Верный пароль или установленный публичный ключ; политика SSH разрешает вход
Чтение файлов/обычные команды Доступ пользователя к файлам и исполняемым программам
Установка или восстановление демона Административные права, необходимые установщику; обычного входа недостаточно
Промежуточный сервер Вход на промежуточный сервер и разрешённая переадресация до цели; аутентификация на цели отдельная

Не выдавайте неограниченный беспарольный sudo ради теста подключения. Пароль SSH — пароль удалённого пользователя, а не пароль входа в Gateway. При проверке нового ключа не отключайте проверку хоста и не удаляйте существующий доступ.

Источник: OpenSSH: authorized_keys и аутентификация сервера.

integrations:ssh:view, integrations:ssh:manage и integrations:ssh:use разделяют просмотр, администрирование и использование. Администрирование доступно только в пользовательской сессии. Gateway MCP не делегирует права внешних SSH-интеграций: внешним агентам нужен собственный разрешённый инструмент SSH. См. API и MCP.

При поддерживаемой установке на ВМ провайдера Gateway проверяет, что SSH ведёт на фактический адрес выбранной ВМ. Рабочее соединение с другим сервером не подходит для её установки. Вместо SSH может использоваться поддерживаемый Guest Agent; само наличие учётной записи провайдера не требует отдельного SSH-подключения.

Разделяйте ошибки DNS и TCP, доступа через промежуточный сервер, несовпадения отпечатка, аутентификации и прав на команду. Получение ключа хоста не подтверждает успешную аутентификацию. Успешный вход не подтверждает права sudo или установки. Исправляйте конкретный уровень по тексту ошибки, не раскрывая пароли и приватные ключи.