Bloques Match de la configuración SSH y aprobación del agente

Una aprobación SSH solo tiene sentido cuando la conexión aprobada es la misma que SSH realizará. Parece obvio, hasta que un agente ejecuta ssh prod, un alias de host selecciona otro HostName, un bloque Match cambia el usuario remoto y ProxyJump envía la sesión a través de un bastión que nadie mencionó en la solicitud.

La mayoría de los errores de configuración SSH se pueden superar cuando una persona observa el terminal. La persona ve una solicitud de clave de host desconocida, detecta root@... o recuerda que prod significa algo distinto en la red de la oficina. Un agente autónomo no tiene ese nivel de desconfianza. Usa el alias que recibe y sigue la configuración al pie de la letra.

Por eso los bloques Match de la configuración SSH merecen una revisión de seguridad antes de dar acceso SSH a un agente. La idea no es prohibir los alias, los bastiones ni la configuración condicional. La idea es que la acción solicitada, la configuración SSH efectiva y la conexión que una persona aprueba describan lo mismo.

Un alias de host es una entrada, no una identidad

ssh app-prod no indica dónde se conectará SSH, qué cuenta usará, qué clave ofrecerá ni si el tráfico pasará primero por otra máquina. Indica a OpenSSH con qué argumento de configuración debe empezar.

La diferencia se difumina porque los alias hacen más cómodo el trabajo diario en la línea de comandos. Un nombre corto como app-prod es más fácil de escribir que un nombre de host completo con un usuario específico y un puerto no estándar. También es más fácil entregárselo a un agente. Pero el alias solo es un identificador. Su significado procede de todos los ajustes coincidentes de los archivos de configuración que SSH lee.

OpenSSH lee primero las opciones de la línea de comandos, después ~/.ssh/config del usuario y, por último, la configuración del sistema. Para la mayoría de las opciones de un solo valor, usa el primer valor que obtiene. El manual ssh_config(5) de OpenSSH deja clara la consecuencia práctica: coloca las declaraciones específicas al principio y los valores predeterminados generales después. Un bloque amplio Host * cerca del principio puede anular silenciosamente una regla condicional posterior más cuidadosa.

Empieza con un inventario que registre cada alias que un agente pueda usar en términos que una persona pueda comprobar:

No escribas production en la columna de destino. Escribe el destino real que usa SSH. No escribas usuario predeterminado. Escribe deploy, ubuntu, ec2-user o la cuenta que reciba el servidor. Si la ruta tiene un host de salto, indícalo. Si el alias se comporta de forma distinta en redes diferentes, necesita su propia fila, porque se trata de una conexión efectiva distinta.

La diferencia útil es esta: un alias identifica una entrada de configuración; un destino identifica el extremo remoto. Confundirlos produce aprobaciones incorrectas. Una persona puede aprobar que un agente abra una sesión hacia staging-api y aun así equivocarse sobre el extremo real porque el alias contiene un comportamiento obsoleto o condicional.

Por eso los alias deberían describir un propósito operativo, no ocultarlo. prod-readonly, prod-deploy y prod-breakfix hacen que la persona revise el punto adecuado. Un único alias llamado prod que elige usuarios, claves y rutas mediante bloques condicionales ahorra unas pulsaciones y crea un problema permanente de revisión.

Los bloques Match son lógica ejecutable de conexión

Un bloque Match no es una etiqueta para un grupo de hosts. Es una sección condicional de ssh_config que cambia qué directivas se aplican. Las condiciones pueden incluir el host solicitado, el host original, el usuario remoto, el usuario local, el estado de canonicalización, la red local, un comando solicitado y un comando exec que SSH ejecuta mediante el shell local.

Ese poder resulta útil. También significa que una configuración puede contener comportamientos invisibles si solo inspeccionas el bloque Host cercano al alias.

Considera esta configuración:

Host prod-api
    HostName api-01.prod.example.net
    User deploy
    ProxyJump prod-bastion

Match originalhost prod-api user root
    IdentityFile ~/.ssh/breakfix_ed25519
    IdentitiesOnly yes

Una persona que solo lea el bloque Host prod-api verá una conexión de despliegue como deploy. Si alguien ejecuta ssh -l root prod-api, puede aplicarse la condición Match originalhost prod-api user root. Que el ajuste de identidad surta efecto también depende de dónde se hayan obtenido antes los ajustes de identidad y de si la opción admite varios valores. El punto importante es más sencillo: la conexión cambió por un argumento de usuario en la línea de comandos, no porque cambiara el alias.

Para el uso de agentes, evita las reglas Match user que concedan una identidad o una ruta más privilegiada. La idea parece ordenada porque agrupa el comportamiento por nombre de cuenta. También es fácil que una herramienta que realiza la llamada la modifique mediante -l, user@host o un comando generado. Coloca el User previsto directamente en un alias específico para ese propósito.

Una versión más segura hace explícita cada intención:

Host prod-deploy
    HostName api-01.prod.example.net
    User deploy
    ProxyJump prod-bastion
    IdentityFile ~/.ssh/prod_deploy_ed25519
    IdentitiesOnly yes

Host prod-breakfix
    HostName api-01.prod.example.net
    User ops
    ProxyJump prod-bastion
    IdentityFile ~/.ssh/prod_breakfix_ed25519
    IdentitiesOnly yes

Esto no vuelve inofensivo el acceso privilegiado. Hace que la conexión solicitada sea fácil de entender. Un agente necesita una autorización independiente para invocar prod-breakfix; no puede llegar a ese comportamiento simplemente cambiando el nombre de usuario.

Match exec merece todavía menos confianza en una configuración destinada a agentes. Ejecuta un comando del shell local mientras SSH evalúa la configuración. Los equipos lo usan para detectar la red, consultar inventarios o seleccionar credenciales. Así, un intento de conexión SSH se convierte en una ruta de código local con dependencias del entorno. Si necesitas esa flexibilidad para el trabajo humano, mantén esos alias fuera del conjunto que el agente puede invocar. Una revisión de conexión no debería exigir la ingeniería inversa de un comando de shell arbitrario.

El primer valor coincidente puede anular tu excepción

El error más persistente de configuración SSH no es una sección inválida. Es una sección válida colocada después de una regla más amplia que ya estableció la opción.

Supón que un desarrollador escribe esto al intentar exigir un bastión para producción:

Host *
    User deploy
    ProxyJump dev-bastion

Host prod-*
    ProxyJump prod-bastion

La expectativa es comprensible: prod-* parece más específico, así que debería ganar. OpenSSH no ordena los bloques según su especificidad. Los procesa en el orden del archivo y, para muchas directivas, gana el primer valor obtenido. prod-api conservará dev-bastion porque el Host * anterior ya proporcionó ProxyJump.

Coloca primero los bloques específicos:

Host prod-*
    ProxyJump prod-bastion

Host *
    User deploy
    ServerAliveInterval 30

No es solo una cuestión de estilo. Una ruta que pase por el bastión equivocado puede colocar la sesión en una ruta de red incorrecta. Un valor predeterminado general User deploy puede hacer que un alias de producción se autentique con una cuenta que no debería estar en ese host. Un IdentityFile general puede ofrecer una credencial inesperada antes que la prevista.

No conviertas la regla del primer valor en una verdad absoluta. Algunas directivas aceptan deliberadamente varios valores, e IdentityFile es un ejemplo habitual. Se pueden añadir varias identidades al conjunto que SSH considera. Eso crea otro problema: un alias específico puede nombrar la identidad correcta, pero dejar disponibles otras identidades procedentes de la configuración anterior o del agente SSH local.

Para las conexiones automatizadas, haz que la selección de identidad sea explícita y predecible:

Host prod-deploy
    HostName api-01.prod.example.net
    User deploy
    IdentityFile ~/.ssh/prod_deploy_ed25519
    IdentitiesOnly yes
    ProxyJump prod-bastion

IdentitiesOnly yes indica a OpenSSH que use solo las identidades configuradas en SSH o proporcionadas en la línea de comandos, en lugar de probar libremente todas las identidades disponibles desde un agente. No corrige una configuración descuidada. Sí evita que una clave ajena cargada en un agente local se convierta en una candidata accidental.

Una recomendación común dice que hay que poner todos los valores predeterminados en Host * y sobrescribirlos solo cuando sea necesario. Es razonable para ajustes inofensivos, como los intervalos de mantenimiento de la conexión. Es una mala práctica para la selección de usuarios, rutas, archivos de identidad, puertos, ProxyCommand y reescrituras de hosts. Los valores predeterminados que afectan a la autoridad deben ser escasos. Repetir un poco la configuración cuesta menos que explicar por qué un agente llegó a la máquina correcta por la ruta equivocada.

ProxyJump crea otra conexión que también debe revisarse

ProxyJump no adorna una conexión al destino. SSH se conecta primero al host de salto y después establece desde ese host una ruta de reenvío TCP hasta el destino. Se pueden indicar varios proxys y atravesarlos en secuencia. El manual de OpenSSH también advierte que la configuración del host de destino, por lo general, no se aplica a los hosts de salto.

Ese último detalle es donde suelen fallar las revisiones. Una configuración puede ser precisa con prod-api y completamente ambigua con prod-bastion.

Host prod-api
    HostName 10.40.8.17
    User deploy
    ProxyJump prod-bastion

Host prod-bastion
    HostName bastion.prod.example.net
    User jump
    IdentityFile ~/.ssh/bastion_ed25519
    IdentitiesOnly yes

Aquí hay dos decisiones de autenticación y dos identidades de host:

1. SSH autentica el cliente local en bastion.prod.example.net como jump.
2. El bastión reenvía un flujo TCP hacia 10.40.8.17.
3. SSH se autentica a través de ese flujo en el destino como deploy.

El host de salto puede tener otra clave, usuario, puerto y registro de clave de host. También puede seleccionarse mediante un alias comodín o un bloque condicional que nadie comprueba porque el agente solo solicitó prod-api.

Revisa cada salto con ssh -G, no solo el alias final:

ssh -G prod-api | egrep '^(hostname|user|port|proxyjump|identityfile|identitiesonly) '
ssh -G prod-bastion | egrep '^(hostname|user|port|identityfile|identitiesonly) '

La salida tiene una opción por línea. Una revisión correcta podría mostrar esta estructura:

hostname api-01.prod.example.net
user deploy
port 22
proxyjump prod-bastion
identityfile ~/.ssh/prod_deploy_ed25519
identitiesonly yes

Después verifica el bastión por separado. Si prod-api usa una cadena separada por comas como edge-bastion,prod-bastion, ejecuta el comando para ambos alias. Una cadena no es una ruta opaca. Son varias configuraciones independientes del cliente SSH.

Evita definir una ruta de salto genérica en Host * o en un patrón amplio como Host *.internal. Tiende a capturar hosts temporales, entornos de staging y alias añadidos meses después. Define la ruta de salto en los alias que la necesitan. Si muchos alias de producción la requieren, usa un patrón estrecho reservado para alias de producción y no lo reutilices sin cuidado.

Comprueba también ProxyCommand. OpenSSH trata ProxyJump y ProxyCommand como opciones que compiten entre sí: la que se especifica primero impide que las instancias posteriores de la otra surtan efecto. Una configuración que parece usar un bastión puede estar ejecutando en realidad un comando proxy anterior. La revisión debe señalar cualquiera de los dos ajustes, porque ambos cambian el lugar desde el que se origina la conexión de red y la forma en que llega al destino.

La selección del usuario cambia la autoridad aprobada

La cuenta remota forma parte de la acción solicitada. [email protected] y [email protected] pueden llegar al mismo servidor, pero no tienen la misma autoridad, perfil de shell, comandos forzados, permisos de sudo ni registro de auditoría.

SSH puede obtener el usuario remoto de varios lugares: user@host en el comando, ssh -l user host, una directiva User o el usuario local si ninguna otra fuente proporciona uno. Una revisión de configuración que solo pregunta «¿Qué host?» está incompleta.

Usa alias que fijen el usuario cuando un agente tenga una tarea definida:

Host inventory-read
    HostName inventory.prod.example.net
    User inventory_ro
    IdentityFile ~/.ssh/inventory_ro_ed25519
    IdentitiesOnly yes

Host inventory-deploy
    HostName inventory.prod.example.net
    User deploy
    IdentityFile ~/.ssh/inventory_deploy_ed25519
    IdentitiesOnly yes

No entregues a un agente un nombre de host genérico pensando que una solicitud o un envoltorio lo mantendrá en la cuenta correcta. Un generador de comandos puede emitir [email protected] con la misma facilidad que [email protected]. La configuración debe hacer que la ruta autorizada sea la más sencilla y que las rutas privilegiadas se distingan claramente.

Prueba las formas alternativas que una herramienta puede generar:

ssh -G inventory-read | grep '^user '
ssh -G -l ops inventory-read | grep '^user '
ssh -G ops@inventory-read | grep '^user '

Si el segundo o el tercer comando produce una cuenta que no querías que usara un agente, no consideres revisada la configuración. Corrige la interfaz de llamada o aísla ese alias. Un bloque Match user también puede activarse con una de estas variantes, por eso necesita pruebas explícitas y no solo una inspección visual.

Para los equipos, reserva el acceso root a un alias de emergencia con un nombre independiente y mantenlo fuera de los permisos habituales de los agentes. Ocultar User root detrás de una condición Match es peor que escribirlo claramente. La condición se convierte en una búsqueda complicada durante un incidente y, en ocasiones, una persona que llama puede satisfacerla cambiando un parámetro de la línea de comandos.

IdentityFile controla más que la ruta de la clave

IdentityFile parece un ajuste para seleccionar archivos. En la práctica, decide qué credencial puede presentar SSH y, por tanto, qué reglas de autorización remotas evaluará el servidor.

Un error habitual tiene este aspecto:

Host *
    IdentityFile ~/.ssh/id_ed25519

Host prod-*
    IdentityFile ~/.ssh/prod_ed25519

El operador cree que producción usa prod_ed25519. SSH puede tener ambos archivos de identidad en su lista de candidatos porque IdentityFile admite varias entradas. Si un agente SSH contiene claves adicionales y falta IdentitiesOnly, también puede ofrecerlas. Algunos servidores rechazan pronto las ofertas repetidas y otros aceptan una identidad no prevista que casualmente concede acceso. Ninguno de los dos resultados expresa bien la intención.

Un alias destinado a un agente debe indicar un único propósito de credencial y limitar las ofertas:

Host reports-export
    HostName reports.prod.example.net
    User exporter
    IdentityFile ~/.ssh/reports_export_ed25519
    IdentitiesOnly yes

Después examina la configuración efectiva en lugar de confiar en la sección:

ssh -G reports-export | grep '^identityfile '
ssh -G reports-export | grep '^identitiesonly '

Más de una línea identityfile no es necesariamente incorrecto. Las configuraciones basadas en certificados y una rotación de claves planificada pueden justificarlo. Pero cada identidad incluida debe pertenecer al mismo límite de autoridad. Si un alias puede ofrecer una clave personal de administrador, una clave de despliegue antigua y una clave de automatización de producción, no tiene una historia de autorización clara.

No resuelvas esto guardando claves privadas en los archivos, el entorno, las solicitudes o los scripts generados por el agente. Eso solo convierte una ambigüedad de configuración en una exposición de credenciales. Sallyport guarda las claves SSH en su bóveda cifrada y ejecuta las acciones SSH mediante su ayudante, pero no puede hacer que una configuración SSH ambigua sea coherente. El alias, la ruta, el usuario y la intención de la identidad deben seguir siendo claros antes de que un operador apruebe el proceso del agente.

La misma regla se aplica a los nombres de las claves. Una ruta como ~/.ssh/id_ed25519 no dice nada sobre el uso previsto. prod_deploy_ed25519 es mejor, pero la configuración necesita la explicación completa: qué grupo de hosts, qué usuario y qué ruta la usan. Los nombres de archivo ayudan a revisar, pero no sustituyen la revisión.

La canonicalización puede hacer que un alias coincida dos veces

La canonicalización de nombres de host es una de las formas menos visibles en que SSH cambia la configuración. Cuando CanonicalizeHostname yes está activado, OpenSSH puede tomar un nombre no cualificado, añadir sufijos de dominio configurados, resolverlo y volver a procesar la configuración con el nuevo nombre de destino. Match canonical se aplica en ese segundo paso. Match final solicita un análisis final y coincide durante ese paso; cuando la canonicalización está activada, las condiciones canonical y final coinciden juntas.

Ese comportamiento puede resultar útil en redes internas grandes. También puede convertir un alias corto en una trampa de configuración condicional.

CanonicalizeHostname yes
CanonicalDomains corp.example.net

Host build
    User ci

Match canonical host *.prod.example.net
    ProxyJump prod-bastion

La persona ejecuta ssh build. En el primer paso se ve build. Si la canonicalización resuelve ese nombre como build.prod.example.net, SSH vuelve a analizar la configuración y el bloque Match canonical host *.prod.example.net puede establecer una ruta de producción. La conexión no cambió porque la persona solicitara otro alias. Cambió porque DNS y un segundo análisis modificaron el host que vieron las reglas posteriores.

El manual de OpenSSH distingue dos condiciones que a menudo se tratan como equivalentes:

• Match originalhost comprueba el token de host tal como lo proporcionó la persona que llama.
• Match host comprueba el destino después de sustituir HostName o aplicar la canonicalización.

Usa originalhost cuando debas vincular el comportamiento a un alias elegido deliberadamente. Usa host cuando el comportamiento deba depender del destino realmente resuelto. No uses ninguno de los dos de forma casual para cambiar privilegios.

La canonicalización tiene otro detalle importante con los bastiones. CanonicalizeHostname yes normalmente no se aplica a conexiones que usan ProxyCommand o ProxyJump; CanonicalizeHostname always la extiende a las conexiones mediante proxy. Eso significa que dos alias con una estructura parecida pueden seguir reglas de reescritura distintas solo porque uno tiene un host de salto.

Para los permisos de los agentes, la política más sencilla suele ser la mejor: desactiva la canonicalización en los alias que se entreguen a un agente y usa valores HostName completos y explícitos. Si tu entorno necesita canonicalización, prueba cada alias permitido en el contexto exacto de red donde se ejecutará el agente. No supongas que un nombre corto se resuelve igual en una red doméstica, una red corporativa, una VPN y la red Wi-Fi de la oficina.

Match localnetwork plantea la misma preocupación. OpenSSH documenta que la dirección de la red local no es fiable para configuraciones sensibles desde el punto de vista de la seguridad, especialmente en redes configuradas mediante DHCP. Puede servir para ajustes de comodidad. No lo uses para decidir si un agente recibe una identidad más privilegiada, evita un bastión o llega a producción.

Renderiza la conexión antes de autorizarla

ssh -G es la forma más rápida de convertir la configuración SSH, que suele leerse como prosa, en algo que se pueda probar. Imprime la configuración que SSH usará después de procesar las reglas Host y Match, y termina sin abrir una conexión.

Ejecútalo con el alias y los argumentos exactos que usará el agente. No pruebes solo una versión limpiada manualmente del comando.

ssh -G prod-deploy | egrep '^(hostname|user|port|proxyjump|proxycommand|identityfile|identitiesonly|canonicalizehostname) '

Para una revisión seria, guarda toda la salida como un artefacto de prueba en el repositorio que controla la automatización. Usa un archivo de configuración con un nombre intencionado para que la prueba no herede silenciosamente los ajustes personales de un desarrollador:

ssh -F ./agent-ssh-config -G prod-deploy > ./testdata/prod-deploy.effective

Revisa el artefacto cuando cambie la configuración. Una diferencia útil detecta un cambio en hostname, user, proxyjump o la lista de identidades antes de que llegue al flujo de aprobación. Una diferencia ruidosa de la configuración completa sigue siendo mejor que confiar en una sección que alguien pegó en una solicitud de cambios.

Usa ssh -vvv solo después de que ssh -G muestre los valores esperados. Los registros detallados de conexión ayudan a confirmar qué claves de host y métodos de autenticación prueba SSH, pero mezclan las decisiones de configuración con el ruido de la red. -G responde primero a «¿Qué dice esta configuración?». Esa es la pregunta que debes resolver antes de investigar la conectividad.

Prueba las variaciones de forma deliberada:

ssh -F ./agent-ssh-config -G prod-deploy
ssh -F ./agent-ssh-config -G -l ops prod-deploy
ssh -F ./agent-ssh-config -G ops@prod-deploy
ssh -F ./agent-ssh-config -G prod-deploy.prod.example.net

Los resultados deben mantenerse dentro del límite de autoridad esperado o fallar. Si una sustitución de usuario cambia la cuenta, si una forma con el nombre completo evita el bastión o si un nombre corto obtiene otra identidad después de la canonicalización, has encontrado una ruta de configuración que conviene cerrar.

Comprueba también los archivos incluidos. Include puede hacer que el ~/.ssh/config visible sea solo la entrada a un directorio lleno de reglas generadas por máquinas, reglas corporativas o reglas específicas de proyectos. Revisa la salida efectiva con la misma cuenta local y la misma ruta de configuración que ejecutará el agente. Probar desde tu propio shell mientras el agente usa otra cuenta crea una falsa sensación de certeza.

Mantén pequeña y específica la configuración SSH para agentes

La mejor configuración SSH para un agente de programación autónomo normalmente no es tu configuración personal con unos cuantos comentarios añadidos. Las configuraciones personales acumulan atajos, excepciones del cliente, alias antiguos, comportamientos ligados a la red local, agentes reenviados e identidades que alguna vez resultaron prácticas. Un agente necesita un catálogo limitado de conexiones.

Crea un archivo de configuración dedicado que contenga solo los alias aprobados y los hosts de salto necesarios para ellos. Indica ese archivo al agente o a su envoltorio de ejecución mediante -F. Dale a cada alias una sola función, un HostName, un User, una ruta y una intención de identidad explícitos. Mantén fuera la lógica condicional salvo que puedas demostrar por qué un alias estático no puede realizar el trabajo.

Un ejemplo compacto sería este:

Host prod-bastion
    HostName bastion.prod.example.net
    User jump
    IdentityFile ~/.ssh/prod_bastion_ed25519
    IdentitiesOnly yes

Host prod-deploy
    HostName api-01.prod.example.net
    User deploy
    ProxyJump prod-bastion
    IdentityFile ~/.ssh/prod_deploy_ed25519
    IdentitiesOnly yes

Host staging-deploy
    HostName api-01.staging.example.net
    User deploy
    IdentityFile ~/.ssh/staging_deploy_ed25519
    IdentitiesOnly yes

Esta configuración se repite. Bien. El archivo permite a una persona revisar qué significa cada conexión sin tener que ejecutar mentalmente la precedencia de comodines y el estado condicional.

No confundas un archivo de configuración dedicado con un motor de políticas. No puede demostrar que un comando sea seguro una vez abierta la sesión. Sí puede hacer que la conexión de transporte sea concreta y fácil de revisar: este alias, este extremo, este usuario, esta ruta, esta identidad. Es un límite útil.

La autorización por sesión de Sallyport y sus registros de actividad proporcionan a los operadores un punto de control humano y un rastro de las acciones del agente, pero la configuración SSH sigue aportando los datos que sustentan la acción. Si prod-deploy puede transformarse en varias rutas de red o cuentas, la configuración ya ha hecho menos fiable la aprobación.

Antes de permitir que un agente use un alias SSH, renderízalo, inspecciona cada host de salto y prueba las variantes de la línea de comandos que el agente pueda producir. Si la conexión efectiva te sorprende una vez, asume que sorprenderá a alguien en el peor momento posible. Corrige el alias hasta que parezca una aprobación que una persona pueda conceder de verdad.