Haga que ssh resuelva los nombres de host desde la configuración cuando use ProxyCommand y el modo netcat

Haga que ssh resuelva los nombres de host desde la configuración cuando use ProxyCommand y el modo netcat

Estoy intentando configurar algunas opciones universales para rebotar conexiones ssh. Aquí está mi ~/.ssh/configarchivo, abreviado:

Host *%via
  ProxyCommand ssh gateway -W $(echo %h | cut -d%% -f1) %p

Host gateway
  HostName gateway.example.com
  User username
  ForwardAgent yes
  IdentityFile keypathg

Host target
  User username
  HostName target.example.com
  IdentityFile keypatht

Cuando utilizo *%vialos Hostalias, obtengo:

% ssh -vvv target%via
OpenSSH_5.9p1, OpenSSL 0.9.8y 5 Feb 2013
debug1: Reading configuration data /Users/myuser/.ssh/config
debug1: /Users/myuser/.ssh/config line 5: Applying options for *
debug1: /Users/myuser/.ssh/config line 12: Applying options for *%via
debug1: Reading configuration data /etc/ssh_config
debug1: /etc/ssh_config line 20: Applying options for *
debug1: auto-mux: Trying existing master
debug1: Control socket "/Users/myuser/.ssh/tmp/target%via_22_myuser" does not exist
debug2: ssh_connect: needpriv 0
debug1: Executing proxy command: exec ssh -A gateway -W $(echo target%via | cut -d% -f1):22
debug1: permanently_drop_suid: 501
debug1: identity file /Users/myuser/.ssh/id_rsa type -1
debug1: identity file /Users/myuser/.ssh/id_rsa-cert type -1
debug1: identity file /Users/myuser/.ssh/id_dsa type -1
debug1: identity file /Users/myuser/.ssh/id_dsa-cert type -1
ssh_exchange_identification: Connection closed by remote host

Sin embargo, si utilizo

% ssh target.example.com%via

Llegué al servidor de destino, pero como el usuario equivocado y sin autenticación de clave pública.

IpensarMi pregunta, en este punto, es si este método de rebote, cuando se utiliza ForwardAgent, pasa por mi configuración/entorno ssh completo o solo por las claves. Si son solo claves, ¿se pueden utilizar las primeras de alguna manera?

Mi versión de ssh es 5.9v1, la puerta de enlace es 5.9v1 y el objetivo es 5.3p1. Creo -Wque se introdujo en 5.4, pero ¿eso no debería importar para el cuadro final en línea? utilizar la escuela anterior ncno parece diferente.

He verificado que puedo enviar ssh manualmente a cada cuadro de la línea. Hacerlo indica que no se pasa la información del alias del nombre de host, ya que cuando estoy en la puerta de enlace, no puedo ssh targetpero puedo ssh target.example.com. Esto funciona con la autenticación de clave pública. Por cierto, la puerta de enlace y el destino tienen el mismo nombre de usuario, por lo que esto funciona si no se presiona ninguna configuración.

Si ForwardAgentuna configuración similar no puede enviar esta información, ¿cuál es la forma más sensata de evitarlo, manteniendo un .ssh/config en la puerta de enlace con esta información?

Respuesta1

Vaya, gracias por hacer esta pregunta. Me resulta raro ver a alguien explotar SSH por completo y esta pregunta afecta a un par de áreas.

Esto no es un ProxyCommandproblema. Simplemente ProxyCommandle indica al cliente ssh local que haga algo en preparación antes de intentar hablar con el cliente remoto. Sí, en nuestro caso, hablamos con otra sesión ssh, pero esa sesión simplemente -Wtoma nuestra entrada y la reenvía a otra máquina. Puedes pensar que la sesión ssh preparatoria es completamente independiente. Analogía inevitable con el automóvil: su automóvil es el mismo, independientemente de si tuvo que tomar un ferry para llegar del punto A al punto B.

Esto no es un ForwardAgentproblema. ForwardAgenthace que el cliente local proporcione una función que haga que las claves locales estén disponibles dentro del entorno de la sesión remota. No has pasado de establecer la sesión remota.

Es una .ssh/configcuestión de formato. Tenga en cuenta la segunda y tercera líneas debug1. Enumera qué estrofas de Host se están aplicando desde su archivo .ssh/config. Observa que $ ssh target.example.com%viafunciona, pero con un nombre de usuario y una clave incorrectos. Bueno, la estrofa for Host targetno se está leyendo (lo que proporcionaría el nombre de usuario y el archivo de claves correctos). ¿Qué estrofas se utilizan? *y *%via.

¿Cómo lograr que se aprueben estas opciones? Bueno, lo suficientemente interesante es que el comodín coincide con cadenas de longitud 0. Host target*coincidirá con target, target%viay .target.example.comtarget.example.com%via

Y entonces usted hace la pregunta, ¿sería útil configurar un .ssh/configen la gatewaymáquina? No, no lo sería. Nunca sería leído. Todo sucede desde nuestra máquina local.

Todo lo que he explicado, solo responde por qué $ ssh target.example.com%viano funciona.

Prefieres $ ssh target%via. Con razón, es más conveniente. El formulario corto falla porque, como nombre de host, targetno se encuentra; no se está resolviendo. ¿Por qué no se arroja ssh: ssh: Could not resolve hostname target: Name or service not known? Porque ProxyCommandya se ha establecido con éxito. Se han creado elementos de una conexión ssh, pero la falla del nombre de host ocurre donde no se esperaba, por lo que está bombardeando con el mensaje más genérico. Presentaría un informe de error sobre esto para ayudar a identificar dónde se podría mejorar la información de depuración.

Comentario final:

Me gusta la Host *%viasintaxis. Es limpio pero flexible. Lo había visto anteriormente Host *+*y utiliza tanto la primera como la última parte %h(ost)para determinar adónde ir. Pero se necesita un poco más de esfuerzo para entender eso. enlace:http://wiki.gentoo.org/wiki/SSH_jump_host

información relacionada