amazon web services - with - Permissão negada(publickey) quando o acesso SSH à instância do Amazon EC2

É sensível a maiúsculas e minúsculas

Errado: SSH EC2-user @ XXX.XX.XX.XX -i MyEC2KeyPair.pem

Correto: SSH ec2-user @ XXX.XX.XX.XX -i MyEC2KeyPair.pem

É uma coisa básica, mas sempre confirme qual usuário você está tentando fazer o login. Im meu caso foi apenas uma distração . Eu estava tentando usar um usuário root :

ssh -i ~/keys/<key_name> [email protected]

Mas foi outro usuário :

ssh -i ~/keys/<key_name> [email protected]

Aqui está um possível cenário frustrante que produz este erro:

Se você estiver almoçando uma nova instância de uma AMI criada por outra instância (digamos, xyz de instância), a nova instância aceitará apenas a mesma chave usada pela instância A. Isso é totalmente compreensível, mas fica confuso porque durante o processo passo a passo de criação da nova instância, você é solicitado a selecionar ou criar uma chave (na última etapa) que não funcionará.

Independentemente da chave que você criar ou selecionar, somente a chave que você estava usando, por exemplo, XYZ, será aceita pela nova instância.

Esqueci de adicionar o nome de usuário (ubuntu) ao conectar minha instância do Ubuntu. Então eu tentei isso:

ssh -i /path/my-key-pair.pem my-ec2-instance.amazonaws.com

e o caminho correto foi

ssh -i /path/my-key-pair.pem [email protected]

Este problema pode ser resolvido pelo login na caixa Ubuntu usando o comando abaixo:

ssh -i ec2key.pem [email protected]

Eu era capaz de SSH de uma máquina, mas não de outra. Acontece que eu estava usando a chave privada errada.

A maneira que eu descobri foi pegando a chave pública da minha chave privada, assim:

ssh-keygen -y -f ./myprivatekey.pem

O que saiu não correspondeu ao que estava em ~/.ssh/authorized_keys na instância do EC2.

Eu já tinha duas chaves e a linha de comando ssh correta (eu sei porque estou duplicando uma instância do Ubuntu 14.04), mas não consegui fazer o ssh em uma nova instância, mesmo depois de esperar 5 minutos como sugerido por Wade Anderson acima.

Eu tive que destruir e recriar a máquina. Isso aconteceu em duas ocasiões separadas. Como não posso entrar inicialmente, não vejo o que está errado.

Então, se você tiver esse problema, tente isso.

Eu lutei com a mesma permissão negada erro aparentemente devido a

key_parse_private2: missing begin marker 

Na minha situação, a causa era o arquivo de configuração ssh do usuário atual (~ / .ssh / config).

Usando o seguinte:

ssh -i ~/myKey.pem [email protected]<IP address> -v 'exit'

A saída inicial mostrou:

debug1: Reading configuration data /home/ec2-user/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 56: Applying options for *
debug1: Hostname has changed; re-reading configuration
debug1: Reading configuration data /home/ec2-user/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config

... muitas linhas de depuração cortadas aqui ...

debug1: Next authentication method: publickey
debug1: Trying private key: /home/ec2-user/somekey.pem
debug1: key_parse_private2: missing begin marker
debug1: read PEM private key done: type RSA
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.

A terceira linha acima é onde o problema real foi identificado; no entanto, procurei na mensagem de depuração quatro linhas da parte inferior (acima) e fui enganado. Não há problema com a chave, mas eu testei e comparei outras configurações.

Meu arquivo de configuração ssh do usuário redefine o host por meio de uma configuração global não intencional, conforme mostrado abaixo. A primeira linha do Host não deveria ter sido um comentário.

$ cat config
StrictHostKeyChecking=no
#Host myAlias
        user ec2-user
        Hostname bitbucket.org
#        IdentityFile ~/.ssh/somekey
#        IdentitiesOnly yes

Host my2ndAlias
        user myOtherUser
        Hostname bitbucket.org
        IdentityFile ~/.ssh/my2ndKey
        IdentitiesOnly yes

Espero que alguém ache isso útil.

Eu resolvi o problema apenas colocando sudo antes

sudo ssh -i mykey.pem myec2.amazonaws.com

Mas a solução adequada é alterar primeiro a propriedade e, em seguida, conectar-se como usuário normal, como Janus Troelsen disse abaixo. No meu caso seria:

chown wellington:wellington key.pem

Eu tive o mesmo erro, mas situação diferente. para mim aconteceu de repente depois de muito tempo eu poderia ssh com sucesso para o meu computador remoto lá fora. depois de muita pesquisa a solução para o meu problema foram as permissões de arquivo. É estranho, é claro, porque eu não mudei nenhuma permissão no meu computador ou o remoto pertencente aos arquivos / diretórios do ssh. então, da boa wiki do archlinux, aqui está:

Para a máquina local, faça isso:

$ chmod 700 ~/
$ chmod 700 ~/.ssh
$ chmod 600 ~/.ssh/id_ecdsa

Para a máquina remota, faça isso:

$ chmod 700 ~/
$ chmod 700 ~/.ssh
$ chmod 600 ~/.ssh/authorized_keys

depois disso meu ssh começou a trabalhar novamente sem a permissão negada (publickey).

Eu tive um erro semelhante

debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Trying private key: xxxx.pem
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.
Permission denied (publickey).

Meu problema é que a instância não foi iniciada corretamente devido a um erro no script de execução na inicialização da Step 3: Configure instance detail em Advanced details:

O que eu pensei que eu entrei:

#include https://xxxx/bootstrap.sh

O que realmente entrou quebra a configuração da instância

#include

https://xxxx/bootstrap.sh

Portanto, a chave pública no lado da instância não foi criada

Foi assim que resolvi o problema

ssh -i <key> [email protected]<ec2 ip>

Minha chave privada foi definida para permissão 400 e estava resultando em permissão negada definindo-o para '644' me ajudou.

key_load_private_type: Permissão negada é o erro específico que eu estava recebendo

Solução: Sudo chmod 644 <key.pem>

Nota: definido como 644 é must, não estava funcionando com 400

Neste caso, o problema surge do par de chaves perdidas. Sobre isso:

• Não há como alterar o par de chaves em uma instância . Você precisa criar uma nova instância que use um novo par de chaves.
• Você pode contornar o problema se sua instância for usada por um aplicativo no Elastic Beanstalk .

Você pode seguir estas etapas:

1. Acesso ao Console de gerenciamento da AWS
2. Guia Open Elastic Beanstalk
3. Selecione seu aplicativo na guia Todas as Aplicações
4. Do lado esquerdo menu selecione Configuração
5. Clique no botão Instances Gear
6. Em Formulário de Servidor, verifique a entrada Par de Chaves do EC2 e selecione seu novo Par de Chaves. Pode ser necessário atualizar a lista para ver um novo par de chaves que você acabou de criar.
7. Salve 
8. O Elastic Beanstalk criará para você novas instâncias associadas ao novo par de chaves.

Em geral, lembre-se de que você deve permitir que sua instância do EC2 aceite o tráfego SSH de entrada.

Para fazer isso, você precisa criar uma regra específica para o Grupo de segurança de sua instância do EC2. Você pode seguir estes passos.

1. Acesso ao Console de gerenciamento da AWS
2. Abrir guia do EC2
3. Na lista Instâncias, selecione a instância na qual você está interessado
4. Na guia Descrição, digite o nome do grupo de segurança que sua instância está usando.
5. Novamente na guia Descrição, clique em Visualizar regras e verifique se o seu Grupo de segurança tem uma regra para o tráfego ssh de entrada na porta 22
6. Se não, em Network & Security menù selecione Security Group
7. Selecione o grupo de segurança usado por sua instância e clique na guia Entrada
8. À esquerda da guia Entrada, você pode compor uma regra para o tráfego de entrada do SSH:
   • Crie uma nova regra : SSH
   • Fonte : endereço IP ou sub - rede da qual você deseja acessar a instância
   • Nota : Se você deseja conceder acesso ilimitado à sua instância, pode especificar 0.0.0.0/0 , embora a Amazon não recomende essa prática.
9. Clique em Add Rule e, em seguida, Apply Your Changes
10. Verifique se você pode se conectar à sua instância por meio do SSH.

Espero que isso possa ajudar alguém como me ajudou.

Outra causa possível desse erro:

Quando o diretório inicial do usuário é grupo gravável , o usuário não pode efetuar login.

(Reproduzido na instância do Ubuntu)

Outro problema possível: ID de login incorreto

Verifique 'instruções de uso'

Todas as boas sugestões acima, mas o que eu encontrei foi que eu selecionei uma instância pré-fabricada. Após o início da instância, observe as instruções de uso. Eu usei incorretamente ID de login da chave privada quando nas instruções eu deveria usar 'bitnami' (por exemplo, bitnami @ domain -i key.pem)

Tente usar

sudo ssh -i mykey.pem [email protected]<ec2_ip_public_dns>

OU

sudo ssh -i mykey.pem [email protected]<ec2_ip_public_dns>

Todas as respostas acima são precisas e devem funcionar na maioria dos casos. No caso de eles não terem, como no meu caso, eu simplesmente me livrei do meu ~/.ssh/known_hosts na máquina que eu estava tentando ssh e que resolveu o problema para mim. Eu consegui me conectar depois.

para o ubuntu 12,04 lts micro instância eu tive que definir o nome de usuário como opção

ssh -i pemfile.pem -l ubuntu dns

você deve verificar estas poucas coisas:

1. Verifique se o seu endereço IP está correto
2. Verifique se você está usando a chave correta
3. Certifique-se de que você está usando o nome de usuário correto, você pode tentar: 3.1. admin 3.2. ec2-user 3.3. ubuntu

Eu tive o mesmo problema, e resolveu depois que mudei o nome de usuário para o ubuntu. Na AWS, a documentação foi mencionada para o usuário ec2-user, mas de alguma forma não funciona para mim.