☰

Host de salto SSH SIN reenvío de agentes

tag-icon • tag-icon ubuntu ssh firewall public-key
Host de salto SSH SIN reenvío de agentes

Aunque es una pregunta sencilla, llevo días buscándola sin éxito.

M = My machine 
J = Jump Host
S = Server

Jump Host has my public key on authorized_keys.
Server has J's public key on authorized_keys.

Allowed connections (due to key authentication):
M -> J
J -> S

¿Cómo puedo acceder a Ssh desde mi máquina?

Mi configuración actual es:

host jump
  user root
  HostName x.x.x.x

host server
  user root
  HostName x.x.x.x
  port 22
  ForwardAgent no
  ProxyCommand ssh jump -W %h:%p

No funciona porque intenta iniciar sesión con la clave M.

Aquí está el registro ssh

debug1: Host 'x.x.x.x' is known and matches the ECDSA host key.
debug1: Found key in /Users/xxxxx/.ssh/known_hosts:1542
...
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /Users/xxxxx/.ssh/id_rsa
debug1: Authentications that can continue: publickey
debug1: Trying private key: /Users/xxxxx/.ssh/id_dsa
debug1: Trying private key: /Users/xxxxx/.ssh/id_ecdsa
debug1: Trying private key: /Users/xxxxx/.ssh/id_ed25519
debug1: No more authentication methods to try.
Permission denied (publickey).
Killed by signal 1.

Respuesta1

El problema es que está intentando usar mi clave (M) para autenticarse en S cuando se supone que debe usar la clave de J. No puedo especificar la clave para usar con IdentityFile porque está en J y no en mi máquina.

Bueno, ese es tu problema. La conexión tanto con el host de salto como con el destino final se inicia directamente desde su cliente en esta configuración. Su cliente debe tener la clave correcta para ambos sistemas.

El ssh jump -W %h:%pcomando del proxy inicia una sesión ssh en su host de salto, pero no crea un shell, simplemente crea un túnel directamente al host de destino. Luego, su cliente realiza un ssh al túnel. En ningún momento se inicia un shell en el host de salto que le permitiría acceder a las claves almacenadas en ese host intermedio en este tipo de configuración. Jugar con el reenvío no sirve de nada. No se utiliza ningún reenvío para iniciar la conexión.

Respuesta2

No inicia sesión en el firewall, es un dispositivo de red que restringe los paquetes. Es básicamente invisible en este escenario. Debe configurarse para permitir que sus paquetes lleguen a su servidor host bastión (jumphost), que es el puerto de entrada 22 y probablemente los puertos de salida de alto rango.

Usted inicia sesión directamente en el servidor, por lo que debe configurarse para permitir esto. Pruebe esto desde otra máquina en la misma red. Desde este host bastión puede iniciar sesión en las máquinas que protege en sus subredes privadas.

Actualización basada en más información. No necesita la clave de host de bastión/salto en el servidor de destino, necesita su clave. No es el bastión que intenta acceder al servidor, es un usuario, es decir, usted.

Da un paso atrás. Asegúrese de poder acceder al servidor de destino mediante ssh desde otro servidor en la misma subred, utilizando su clave. Luego pruébalo desde el host bastión.

información relacionada