Estoy intentando conectarme a través de una puerta de enlace a una instancia EC2.
Si me conecto a la puerta de enlace
local> ssh gateway
Entonces puedo conectarme a EC2 sin contraseña.
gateway> ssh ec2 # works
Sin embargo, intentar conectarse a través del proxy parece requerir el archivo de identidad.
Host gateway
HostName <gateway>
Host ec2
HostName ec2-<ec2>.compute.amazonaws.com
ProxyCommand ssh gateway -W %h:%p
local> ssh ec2
Permission denied (publickey).
Pensé que ProxyCommand básicamente me registraba en la puerta de enlace y luego iniciaba sesión en el destino final. Si es así, ¿por qué me pediría la clave pública cuando la puerta de enlace está configurada para no requerirla? ¿Cómo puedo conectarme a la instancia ec2 de la misma manera que si ingresara a la puerta de enlace y luego ingresara a ec2?
Editar: rsync funciona normalmente (no solicita el archivo clave)
rsync -pthrvz --rsync-path=/usr/bin/rsync --rsh='ssh gateway ssh' . ec2:/path
ssh -v salida degateway> ssh ec2
gateway> ssh -v ec2
OpenSSH_5.3p1, OpenSSL 1.0.1e-fips 11 Feb 2013
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to ec2 port 22.
debug1: Connection established.
debug1: identity file <snip> type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.2
debug1: match: OpenSSH_6.2 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.3
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'ec2' is known and matches the RSA host key.
debug1: Found key in ~/.ssh/known_hosts:63
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Trying private key: ~/.ssh/identity
debug1: Offering public key: ~/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 277
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).
debug1: channel 0: new [client-session]
debug1: Requesting [email protected]
debug1: Entering interactive session.
debug1: Sending environment.
Salida de ssh -v al intentar conectarse a través de proxy
local$ ssh -v ec2
OpenSSH_6.7p1 Ubuntu-5ubuntu1.3, OpenSSL 1.0.1f 6 Jan 2014
debug1: Reading configuration data /home/matt/.ssh/config
debug1: /home/matt/.ssh/config line 9: Applying options for ec2
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Hostname has changed; re-reading configuration
debug1: Reading configuration data /home/matt/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Executing proxy command: exec ssh gateway -W ec2:22
debug1: permanently_drop_suid: 1000
debug1: identity file /home/matt/.ssh/id_rsa type 1
debug1: key_load_public: No such file or directory
debug1: identity file /home/matt/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/matt/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/matt/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/matt/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/matt/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/matt/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/matt/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.7p1 Ubuntu-5ubuntu1.3
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.2
debug1: match: OpenSSH_6.2 pat OpenSSH* compat 0x04000000
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr [email protected] none
debug1: kex: client->server aes128-ctr [email protected] none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA 73:<snip>:0c
debug1: Host 'ec2.compute.amazonaws.com' is known and matches the ECDSA host key.
debug1: Found key in /home/matt/.ssh/known_hosts:11
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/matt/.ssh/id_rsa
debug1: Authentications that can continue: publickey
debug1: Trying private key: /home/matt/.ssh/id_dsa
debug1: Trying private key: /home/matt/.ssh/id_ecdsa
debug1: Trying private key: /home/matt/.ssh/id_ed25519
debug1: No more authentication methods to try.
Permission denied (publickey).
El problema parece ser que está intentando encontrar la clave en mi máquina en lugar de tomarla de la máquina de puerta de enlace.
Respuesta1
ProxyCommand no funciona como cree. El comando especificado no se ejecuta en la máquina de puerta de enlace. Más bien, se ejecuta en la máquina de conexión.
Por tanto, el flujo de ejecución es:
El ProxyCommand "ssh gateway -W %h:%p" se ejecuta en la máquina "local". Esto establece una sesión SSH en la puerta de enlace, utilizando la identidad RSA en su caja local. El indicador -W especifica que stdin y stdout deben conectarse a un origen de sesión TCP en la puerta de enlace a su destino final.
Con la sesión de proxy establecida, ssh en su cuadro local nuevamente usa esa sesión para autenticarse en su servidor SSH remoto, nuevamente, usando credenciales locales.
Es un poco confuso, pero piense en ProxyCommand como simplemente configurar una "tubería" entre su cliente SSH local y el servidor SSH que es su destino final. Luego, su cliente SSH local utiliza esa tubería tonta para comunicarse con el servicio SSH del destino final.
La clave es que hay, por tanto,dosinstancias de SSH ejecutándose en su caja local, una de ellas es ProxyCommand y la otra, la conexión SSH real que desea establecer. Debería poder verificarlo mirando la salida de "ps aux" en su caja local.
Eso explicaría entonces por qué intenta utilizar material clave en su caja local, en lugar de en su puerta de enlace para autenticarse. :-)
La razón por la que rsync funciona es que en realidad estás haciendo "ssh gateway ssh" como tu comando --rsh, que en realidad ejecuta ssh una vez en el cuadro local para conectarse al gateway, y luego una vez más en el cuadro remoto, lo que luego use el material de la llave remota.
Espero que esto ayude.