He estado luchando por establecer una configuración válida para abrir una conexión con una segunda máquina, pasar por otra y usar un id_rsa (que me solicita una contraseña) para conectarme a la tercera máquina.

He hecho esta pregunta en otro foro, pero no he recibido ninguna respuesta que pueda considerarse muy útil.

El problema, mejor descrito, es el siguiente:

Local machine: user1@localhost
Intermediary machine: user1@inter
Remote target: user2@final

Puedo hacer toda la conexión usando pseudo-tty:

ssh -t inter ssh user2@final

(esto me pedirá la contraseña para el archivo id_rsa que tengo en la máquina "inter")

Sin embargo, para acelerar las cosas, me gustaría configurar mi archivo .ssh / config, para que pueda simplemente conectarme a la máquina "final" usando:

ssh final

Lo que tengo hasta ahora, que no funciona, es en mi archivo .ssh / config:

Host inter
    User user1
    HostName inter.com
    IdentityFile ~/.ssh/id_rsa

Host final
    User user2
    HostName final.com
    IdentityFile ~/.ssh/id_rsa_2
    ProxyCommand ssh inter nc %h %p

El archivo id_rsa se usa para conectarse a la máquina central (esto no requiere que escriba una contraseña), y el archivo id_rsa_2 se usa para conectarse a la máquina "final" (este solicita una contraseña).

Intenté mezclar algunos LocalForwardy / o RemoteForwardcampos, y poner los archivos id_rsa en las máquinas primera y segunda, pero no pude tener éxito sin ninguna configuración.

PD: el hilo del que he tratado de obtener ayuda:

http://www.linuxquestions.org/questions/linux-general-1/proxycommand-on-ssh-config-file-4175433750/

MÉTODO 1 (use ssh-key en inter)

Si desea retener el flujo de autenticación

local -- authenticate --> inter -- authenticate (ask password) --> final

Esto no se puede hacer con .ssh / config proxyhost.

Lo que necesitas es un alias de shell bash (espero que estés usando bash).

En ~/.bashrc, agregue la siguiente línea

alias ssh-final='ssh -t inter ssh user2@final.com'

En el símbolo del sistema, simplemente escriba following

ssh-final

finalsección en ~/.ssh/configno se utiliza.

Detalles de conexión (1)

ssh -t inter ssh user2@final.com se puede ver de la siguiente manera

local# ssh inter
inter# ssh user2@final.com

localsolo está "hablando" inter. No hay conexión ssh directa o indirecta entre localy final. localsolo muestra la salida de ssh user2@final.com.

MÉTODO 2 (use ssh-key en local)

Autenticación con la misma clave ssh

Host inter
    User user1
    HostName inter.example.com

Host final
    User user2
    Hostname <final.com / final IP Address>
    Port 22
    ForwardAgent yes
    ProxyCommand ssh inter nc %h %p

Copiar local ~/.ssh/id_ras.pub a

/home/user1/.ssh/authorized_keys in `inter`
/home/user2/.ssh/authorized_keys in `final`

Detalles de conexión (2)

tunelado ssh

Antes de entrar en detalles ProxyCommand, veamos el siguiente ejemplo

Paso 1, en la ventana de terminal 1

local# ssh inter -L 2000:final.com:22

Paso 2, en la ventana de terminal 2

local# ssh localhost -p 2000

En la terminal 1, se configura un túnel entre el puerto local 2000 y el puerto final.com 22. Todo lo que se envíe al puerto local 2000 se enviará al puerto 22 final.com y viceversa.

En la terminal 2, ssh se conecta al puerto local 2000, pero en realidad se está comunicando con el puerto 22 de final.com, que es el sshd.

Con la tunelización, el cliente ssh local en el Paso 2 se conecta directamente con final.com sshd.

La "salida" del puerto local 2000 es el tráfico de daemon ssh "en bruto".

El uso común de dicho túnel es acceder al servidor web interno o al servidor de correo electrónico. El siguiente es un ejemplo para el servidor web

local# ssh inter -L 2000:final.com:80

En el navegador use la siguiente URL

http://localhost:2000

Los dos puntos finales del túnel son el puerto local 2000 y el puerto final.com 80.

Tráfico entrando y saliendo del punto final del túnel "TAL CUAL". Llamemos a eso tráfico "en bruto".

ProxyCommand

Host final
    User user2
    Hostname <final.com / final IP Address>
    Port 22
    ForwardAgent yes
    ProxyCommand ssh inter nc %h %p

Lo ProxyCommandllevan un paso más allá. Se salta el paso de crear un puerto local y conectarse a él.

Un cliente ssh ejecutará cualquier comando que se dé ProxyCommandy tratará la salida de ese comando como tráfico "sin procesar". Se aferra al punto final local y luego inicia una conexión ssh con él.

¿Por qué uno trabaja y el otro no?

El siguiente comando

ssh inter nc final.com 22

básicamente significa (1) conectarse inter, luego (2) encendido inter, ejecutar comando nc final.com 22.

nc - arbitrary TCP and UDP connections and listens

Por nc final.com 22lo tanto, se conectará al puerto 22 de final.com, imprimirá todo el tráfico entrante en stdout y enviará todos los stdin al otro lado. Es un "túnel" entre nc stdin / out y final.com puerto 22.

Como ncse ejecuta dentro de la sesión ssh, toda su stdout se devuelve al cliente ssh, como tráfico "en bruto". Y el cliente ssh puede pasar el tráfico a nc stdin, que terminará en el puerto 22 de final.com.

A través del "túnel" anterior, el cliente ssh local iniciará una sesión ssh final.comdirectamente.

El siguiente comando

ssh -t inter ssh user2@final.com

no funciona ProxyCommandporque el tráfico no es "sin procesar" de un demonio ssh. Es el stdout de un cliente ssh . Hablar con el cliente significa no hacer negocios.

Autenticación con diferentes claves ssh (configuración original de OP)

Host inter
    User user1
    HostName inter.com
    IdentityFile ~/.ssh/id_rsa

Host final
    User user2
    HostName final.com
    IdentityFile ~/.ssh/id_rsa_2
    ProxyCommand ssh inter nc %h %p

Copiar local ~/.ssh/id_ras.pub a

/home/user1/.ssh/authorized_keys in `inter`

Copiar local ~/.ssh/id_ras_2.pub a

/home/user2/.ssh/authorized_keys in `final`

Ambos de los anteriores permitirán el siguiente uso

local# ssh final

Comprobación adicional

Use detallado

local# ssh -v final

Eso debería ayudar a identificar el problema ssh.

Comprobar nc

ProxcyCommandse está ejecutando ncel inter. Compruebe si ncestá realmente disponible en inter.

local# ssh inter
inter# nc final.com 22

Verifique que la clave rsa esté configurada correctamente

Si se van a utilizar diferentes claves para intery final, los siguientes archivos deberían existir en la máquina local

local# ls ~/.ssh
id_rsa id_rsa_2 id_rsa.pub id_rsa_2.pub

Como ya puede hacer ssh inter, verifique la configuración de la tecla final. Desde su máquina local

local# ssh -t inter ssh user2@final
final# cat .ssh/authorized_keys

Deberías ver el contenido de id_rsa_2.puballí.

No vi ningún error en la lista o declaraciones ssh -v que ayudarían a ver dónde está colgando.

Hola hombre, lo tienes casi bien, la mejor y más segura forma es tener ambas llaves en la máquina local. Luego usaría el reenvío de agente ssh para conectarse en lugar de dejar las claves en los pasos intermedios. También tiene la ventaja de tener que escribir su frase clave solo una vez por inicio de sesión.

Si tiene un sistema operativo moderno / fácil de usar como ubuntu (en su máquina local), esto no debería funcionar sin ningún * masaje *. Dejé el archivo de identidad intencionalmente, no lo necesitará.

Su archivo de configuración se vería así:

Host inter
    User user1
    ForwardAgent yes
    HostName inter.com

Host final
    ForwardAgent yes
    User user2
    HostName final.com
    ProxyCommand ssh inter nc %h %p

Si no es así, sigue estos pasos para asegurarte de que ssh-agent se esté ejecutando:

'ssh-add -l' (lower case L) will list your private keys if any are loaded, or will be blank, or will say can’t connect to ssh-agent, if so, start ssh-agent.
'eval `ssh-agent`' (those are backticks) starts ssh agent
'ssh-add' will add your key… you can add a path argument if you have a key in a non-default area. At this point you will enter your passphrase.

Aquí hay una buena guía que explica cómo funciona esto.