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

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

Настройка подключения

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

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

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

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

1. Убедитесь, что сервер Opfield достигает хоста и порта SSH (обычно 22) напрямую либо через настроенный промежуточный сервер.
2. Сгенерируйте ключ в Opfield и скопируйте публичную часть. Не создавайте другой несвязанный ключ локально и не вставляйте приватный ключ в authorized_keys.
3. Через доверенную консоль войдите под нужным удалённым пользователем. Подготовьте его каталог SSH:

mkdir -p ~/.ssh
chmod 700 ~/.ssh
touch ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

4. Откройте ~/.ssh/authorized_keys редактором и добавьте публичный ключ одной строкой, сохранив существующие ключи. Файл и каталог должны принадлежать этому пользователю. Если редактируете от администратора, используйте домашний каталог целевого пользователя, а не администратора.
5. Проверьте ключ сервера через консоль провайдера или другой независимо доверенный канал. Для ключа хоста Ed25519:

ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub -E sha256

6. Сравните SHA-256 отпечаток с предложенным Opfield ключом того же алгоритма. Значение, полученное только через непроверенное соединение, не является независимым подтверждением. Сохраните проверенный отпечаток и проверьте аутентификацию.

Сценарий	Требования к удалённому пользователю
Вход	Верный пароль или установленный публичный ключ; политика SSH разрешает вход
Чтение файлов/обычные команды	Доступ пользователя к файлам и исполняемым программам
Установка или восстановление демона	Административные права, необходимые установщику; обычного входа недостаточно
Промежуточный сервер	Вход на промежуточный сервер и разрешённая переадресация до цели; аутентификация на цели отдельная

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

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

Доступ и установка на ВМ

integrations:ssh:view, integrations:ssh:manage и integrations:ssh:use разделяют просмотр, администрирование и использование. В 2.11 эти области можно также делегировать API-токенам и разрешениям OAuth, а Opfield MCP предоставляет агентам, у которых они есть, набор инструментов внешнего SSH. Согласие OAuth по умолчанию оставляет integrations:ssh:use невыбранным, поэтому выполнение команд через агента нужно разрешить явно. См. API и MCP.

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

Диагностика

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