☰

Instância de sub-rede privada VPC da Amazon Web Service (AWS) 'Permissão negada (chave pública).' -ssh do osx

tag-icon • tag-icon ssh amazon-ec2 amazon-web-services
Instância de sub-rede privada VPC da Amazon Web Service (AWS) 'Permissão negada (chave pública).' -ssh do osx

Estou me conectando a uma instância EC2 do Amazon Web Service (AWS) na sub-rede privada de um servidor virtual privado por meio de uma instância NAT e recebo o seguinte erro:

Permissão negada (chave pública)

Isso aconteceu depois que eu me conectei ao NAT e estou tentando fazer o SSH para a instância EC2 da sub-rede privada.

Procedimento:

  1. Defina host ~/.ssh/configcom o seguinte:

    Host my_aws_nat
Hostname xx.xx.xx.xx
User ec2-user
IdentityFile /location/of/my/aws/key_pair.pem
ForwardAgent yes

  2. Instância SSH para NAT via ssh my_aws_nat(que foi bem-sucedida)

  3. SSH para instância na sub-rede privada - é quando recebo o errossh [email protected]

Consigo executar ping em minha instância privada do meu NAT com ping 10.0.X.X. Portanto, tenho quase certeza de que não é um problema de grupos de segurança. Parece que é um problema de encaminhamento de agente.

Atualmente, a instância à qual estou me conectando usa o mesmo par de chaves da instância NAT (no modo de aprendizagem).

A outra maneira que tentei é conectar-me ao NAT com:

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

Que, novamente, se conecta corretamente ao NAT, mas apresenta o mesmo erro ao conectar-se à instância privada.

Devo usar ssh-agentno Mac OS X?

Ou não deveria especificar ForwardAgent yesin /.ssh/configfazer a mesma coisa?

Responder1

Conformeesseresponda eesta diretriz

Eu precisava adicionar key_pair.pemo agente ssh do OSX da seguinte maneira:

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

(no meu caso não pediu senha)

Depois disso, tudo funcionou bem usando as duas metodologias descritas acima.

Então, para responder à pergunta:

P: Preciso usar o ssh-agent no Mac OS X para fazer login em uma instância de sub-rede privada por meio de um host NAT/bastion?
A: SIM

Responder2

Para mim, ajudou a remover a chave pública do bastião (instância NAT) do ~/.ssh/known_hosts. Se a chave do host bastião remoto for alterada (o que pode acontecer com bastante frequência se você alocar EIPs para novas instâncias) e além disso tiver sido StrictHostKeyChecking nodefinida em seu ssh_config, o AgentForwarding será desabilitado no host bastião. Você também encontrará um aviso informando isso se fizer login no bastion host. De minha parte, simplesmente não li -.-

Portanto, exclua a chave e conecte-se novamente, a chave atual será adicionada ao arquivoknown_hosts e você poderá se conectar à instância na sub-rede privada.

informação relacionada