Instancia de subred privada de VPC de Amazon Web Service (AWS) 'Permiso denegado (clave pública)'. - ssh desde osx

Instancia de subred privada de VPC de Amazon Web Service (AWS) 'Permiso denegado (clave pública)'. - ssh desde osx

Me estoy conectando a una instancia EC2 de Amazon Web Service (AWS) en la subred privada de un servidor privado virtual a través de una instancia NAT y aparece el siguiente error:

Permiso denegado (clave pública)

Esto sucedió después de que me conecté a NAT e intenté conectarme por SSH a la instancia EC2 de la subred privada.

Procedimiento:

  1. Defina host ~/.ssh/configcon lo siguiente:

    Host my_aws_nat
    Hostname xx.xx.xx.xx
    User ec2-user
    IdentityFile /location/of/my/aws/key_pair.pem
    ForwardAgent yes
    
  2. Instancia de SSH a NAT vía ssh my_aws_nat(que es exitosa)

  3. SSH a una instancia en una subred privada , que es cuando aparece el errorssh [email protected]

Puedo hacer ping a mi instancia privada desde mi NAT con ping 10.0.X.X. Así que estoy bastante seguro de que no es un problema de grupos de seguridad. Parece que es un problema de reenvío de agentes.

Actualmente, la instancia a la que me estoy conectando utiliza el mismo par de claves que la instancia NAT (en modo de aprendizaje).

La otra forma que he probado es conectarme a la NAT con:

ssh -A [email protected] -i key_pair.pem

Lo cual nuevamente se conecta correctamente a la NAT pero da el mismo error al conectarse a la instancia privada.

¿Tengo que usarlo ssh-agenten Mac OS X?

¿O no debería especificar ForwardAgent yeshacer /.ssh/configlo mismo?

Respuesta1

segúnesteresponder yesta directriz

Necesitaba agregar key_pair.pemel agente ssh de OSX de la siguiente manera:

ssh-add -K /path/to/key_pair.pem

(en mi caso no me pidió contraseña)

Después de esto, todo funcionó bien utilizando las dos metodologías descritas anteriormente.

Entonces para responder la pregunta:

P: ¿Tengo que usar ssh-agent en Mac OS X para iniciar sesión en una instancia de subred privada a través de un host NAT/bastion?
A:

Respuesta2

A mí me ayudó eliminar la clave pública del bastión (instancia NAT) de ~/.ssh/known_hosts. Si la clave del host bastión remoto cambió (lo que puede suceder con bastante frecuencia si asigna EIP a nuevas instancias) y además la ha StrictHostKeyChecking noconfigurado en su ssh_config, AgentForwarding se desactivará en el host bastión. También encontrará una advertencia que lo indica si inicia sesión en el servidor bastión. Por mi parte simplemente no lo he leído -.-

Entonces, elimine la clave y conéctese nuevamente, la clave actual se agregará al archivo conocido_hosts y podrá conectarse a la instancia en la subred privada.

información relacionada