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.
Configura una conexión
Sección titulada «Configura una conexión»- Abre la sección External SSH en Settings > Integrations.
- 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.
- 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.
- Si hace falta, selecciona una conexión de salto existente y verifica el acceso por esa ruta.
- Descubre la huella de la clave del host y verifícala por un canal de confianza independiente antes de aceptarla.
- 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.
- 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. - 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. - En una consola de confianza, inicia sesión con la cuenta remota prevista. Prepara su directorio SSH:
mkdir -p ~/.sshchmod 700 ~/.sshtouch ~/.ssh/authorized_keyschmod 600 ~/.ssh/authorized_keys- Abre
~/.ssh/authorized_keysen 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. - 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:
ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub -E sha256- 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.
Acceso e instalación en hosting
Sección titulada «Acceso e instalación en hosting»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.
Diagnostica los fallos de conexión
Sección titulada «Diagnostica los fallos de conexión»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.