Ir al contenido

Conexiones SSH

External SSH conecta Opfield con un host remoto con nombre usando una credencial configurada por un administrador. No es un conector de repositorios Git, ni un nodo Bastion gestionado, ni un sustituto del registro de daemons. Usa Hosting de Git para acceder a repositorios y Nodos para las operaciones continuas gestionadas por daemons.

  1. Abre la sección External SSH en Settings > Integrations.
  2. Introduce un nombre visible, el host, el puerto y el usuario remoto. Usa una cuenta que tenga solo los privilegios del sistema operativo necesarios para la operación prevista.
  3. Elige autenticación por contraseña o una clave SSH generada por Opfield. Las conexiones nuevas no aceptan importar claves privadas arbitrarias. Instala la clave pública generada en la cuenta remota; cuando se ofrezca, se puede reutilizar una clave existente compatible.
  4. Si hace falta, selecciona una conexión de salto existente y verifica el acceso por esa ruta.
  5. Descubre la huella de la clave del host y verifícala por un canal de confianza independiente antes de aceptarla.
  6. Guarda la conexión y prueba la autenticación. Si la clave del host cambia, investiga el cambio en lugar de saltarte la verificación.

Las credenciales se guardan cifradas. Un usuario SSH llamado root y el rol de administrador del sistema de Opfield pertenecen a sistemas de autorización distintos: los permisos remotos no siguen el rol del usuario de Opfield.

Prepara la cuenta remota y la clave pública

Sección titulada «Prepara la cuenta remota y la clave pública»

SSH no tiene ámbitos de API del proveedor. Su límite de permisos es la cuenta Unix remota, los permisos de sus archivos y cualquier escalada de privilegios configurada explícitamente.

  1. Asegúrate de que el backend de Opfield puede llegar al host y al puerto SSH (normalmente 22), directamente o a través de la conexión de salto configurada.
  2. En Opfield, genera una clave y copia la clave pública. No generes localmente una segunda clave sin relación ni pegues una clave privada en authorized_keys.
  3. En una consola de confianza, inicia sesión con la cuenta remota prevista. Prepara su directorio SSH:
Ventana de terminal
mkdir -p ~/.ssh
chmod 700 ~/.ssh
touch ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys
  1. Abre ~/.ssh/authorized_keys en un editor y añade la clave pública como una sola línea, conservando las claves existentes. Asegúrate de que el directorio y el archivo pertenecen a esa cuenta. Si editas como administrador, usa el directorio personal de la cuenta de destino, no el del administrador.
  2. Verifica la clave del host del servidor a través de la consola del proveedor o de otro canal de confianza independiente. Para una clave de host Ed25519:
Ventana de terminal
ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub -E sha256
  1. Compara esa huella SHA-256 con la del mismo algoritmo de clave de host que ofrece Opfield. Un valor obtenido solo a través de la conexión no verificada no es una verificación independiente. Guarda la huella verificada y prueba la autenticación.
Uso previsto Requisito de la cuenta remota
Iniciar sesión Contraseña válida o clave pública instalada; inicio de sesión SSH permitido por la política del servidor
Leer archivos o ejecutar comandos ordinarios Acceso a archivos y ejecutables para esa cuenta
Instalar o reparar un daemon Los privilegios administrativos del flujo de instalación; un inicio de sesión ordinario no basta
Usar un jump host Inicio de sesión en el jump host y una ruta de reenvío permitida hacia el destino; la autenticación en el destino sigue siendo independiente

No concedas sudo sin contraseña y sin restricciones solo para superar una prueba de conexión SSH. Una contraseña es la contraseña de la cuenta remota, no una contraseña de inicio de sesión de Opfield. Para la autenticación por clave, no desactives la verificación del host ni el acceso existente mientras pruebas la clave nueva.

Referencia: authorized_keys y autenticación del servidor en OpenSSH.

integrations:ssh:view, integrations:ssh:manage e integrations:ssh:use separan la visibilidad, la administración y el uso. En la 2.11 estos ámbitos también se pueden delegar en tokens de API y concesiones OAuth, y Opfield MCP ofrece un conjunto de herramientas de SSH externo a los agentes que los tienen. El consentimiento OAuth deja integrations:ssh:use sin marcar por defecto, de modo que ejecutar comandos a través de un agente debe seleccionarse explícitamente. Consulta API y MCP.

Para la instalación en hosting compatible, Opfield verifica que el destino SSH sea una dirección realmente asignada a la VM seleccionada. Una conexión que funciona con otro host no es un canal de instalación para esa VM. El hosting puede usar en su lugar un canal Guest Agent compatible; no añadas SSH solo porque exista una cuenta en el proveedor.

Separa la accesibilidad DNS o TCP, el acceso al jump host, una huella que no coincide, el rechazo de la autenticación y el permiso para ejecutar el comando previsto. Descubrir la clave del host no equivale a autenticarse. Iniciar sesión no demuestra tener privilegios de sudo o de instalación. Inspecciona el error concreto y corrige la capa correspondiente sin exponer contraseñas ni claves privadas.