SSH ProxyCommand y autenticación basada en host: ¿qué host firma?
Distinga reenviar un flujo TCP a través de un bastión de iniciar allí un segundo cliente SSH cuando interviene la autenticación basada en host.
Un destino puede ver una conexión TCP que llega desde el bastión mientras el cliente SSH que realiza la autenticación sigue ejecutándose en la estación de trabajo.
Host behind-bastion
ProxyCommand ssh -W %h:%p bastionAquí el auxiliar inicia sesión en el bastión y pide a su servidor SSH una conexión reenviada hacia el destino. El cliente SSH externo de la estación intercambia el protocolo SSH del destino a través de ese flujo. El bastión aporta el transporte; no ha iniciado el cliente SSH dirigido al destino.
Esa distinción importa para la autenticación basada en host. El auxiliar ssh-keysign de OpenSSH accede a las claves de host locales para generar la firma necesaria. Una dirección de origen de red que pertenece al bastión no hace que la estación firme con la clave de host del bastión.
Compárelo con:
ssh -t bastion ssh targetEsto inicia otro programa SSH en el bastión. Su configuración local y las claves de host disponibles pertenecen a esa máquina, así que puede participar en un acuerdo de confianza basado en host ya configurado entre el bastión y el destino. Aun así necesita la autorización correspondiente y las comprobaciones de nombre del destino.
La segunda forma también cambia el funcionamiento de la sesión: ejecuta un comando remoto y usa una terminal. No es un sustituto transparente para toda transferencia de archivos SSH o transporte de automatización. Elija la opción según qué máquina debe autenticarse ante el destino, en lugar de debilitar las comprobaciones de confianza del servidor para que la dirección de origen parezca suficiente.