Permissão negada (chave pública) quando o acesso SSH à instância do Amazon EC2 [fechado]

Quero usar minha instância do Amazon ec2, mas enfrentou o seguinte erro:

Permission denied (publickey).

Eu criei meu par de chaves e baixei o arquivo .pem .

Dado:

chmod  600 pem file.

Então, este comando

ssh -i /home/kashif/serverkey.pem  ubuntu@ec2-54-227-242-179.compute-1.amazonaws.com

Mas tem este erro:

Permission denied (publickey)

Além disso, como posso conectar-me ao filezilla para carregar / baixar arquivos?

Essa mensagem de erro significa que você não conseguiu se autenticar.

Estes são os motivos comuns que podem causar isso:

1. Tentando se conectar com a chave errada. Tem certeza de que esta instância está usando esse par de chaves?
2. Tentando se conectar com o nome de usuário errado. ubuntué o nome de usuário para a distribuição AWS baseado ubuntu, mas em alguns outros é ec2-user(ou adminem alguns Debians, de acordo com a resposta de Bogdan Kulbida) (também pode ser root, fedora, veja abaixo)
3. Tentando conectar o host errado. É o host certo em que você está tentando fazer login?

Observe que 1.isso também acontecerá se você alterou o /home/<username>/.ssh/authorized_keysarquivo na sua instância do EC2.

Sobre 2., as informações sobre qual nome de usuário você deve usar geralmente estão ausentes na descrição da imagem da AMI. Mas você pode encontrar alguns na documentação do AWS EC2, ponto de referência 4.: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AccessingInstancesLinux.html

Use o comando ssh para conectar-se à instância. Você especificará o arquivo da chave privada (.pem) e nome_do_usuário @ nome_dns_public. Para Amazon Linux, o nome de usuário é ec2-user. Para RHEL5, o nome do usuário é root ou ec2-user . Para o Ubuntu, o nome de usuário é ubuntu . Para o Fedora, o nome de usuário é fedora ou ec2-user . Para o SUSE Linux, o nome do usuário é raiz . Caso contrário, se o usuário ec2 e o root não funcionarem, verifique com seu provedor de AMI.

Por fim , esteja ciente de que existem muitos outros motivos pelos quais a autenticação falharia. O SSH geralmente é bastante explícito sobre o que deu errado, se você quiser adicionar a -vopção ao seu comando SSH e ler a saída, conforme explicado em muitas outras respostas a esta pergunta.

Nesse caso, o problema surge do par de chaves perdido. 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 solucionar 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. Abra a guia Elastic Beanstalk
3. Selecione seu aplicativo na guia Todos os aplicativos
4. No lado esquerdo menù selecione Configuration
5. Clique na engrenagem de instâncias
6. No formulário do servidor, verifique a entrada do par de chaves 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ê deve criar uma regra específica para o grupo de segurança da sua instância do EC2. Você pode seguir estas etapas.

1. Acesso ao console de gerenciamento da AWS
2. Abra a guia EC2
3. Na lista Instâncias, selecione a instância em que você está interessado
4. Na guia Descrição, selecione o nome do grupo de segurança que sua instância está usando.
5. Novamente na guia Descrição, clique em Exibir regras e verifique se o seu Grupo de segurança possui uma regra para o tráfego ssh de entrada na porta 22
6. Caso contrário, nos homens de Rede e segurançaù selecione Grupo de Segurança
7. Selecione o grupo de segurança usado por sua instância e clique na guia Entrada
8. À esquerda da guia Entrada, você pode escrever uma regra para o tráfego de entrada SSH:
   • Crie uma nova regra : SSH
   • Origem : 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 esta prática
9. Clique em Adicionar regra e, em seguida, aplique suas alterações
10. Verifique se agora você pode se conectar à sua instância via SSH.

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

Foi assim que resolvi o problema

ssh -i <key> ec2-user@<ec2 ip>

Eu resolvi o problema colocando sudoantes

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

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

chown wellington:wellington key.pem

Tente usar

sudo ssh -i mykey.pem ubuntu@<ec2_ip_public_dns>

OU

sudo ssh -i mykey.pem ec2-user@<ec2_ip_public_dns>

Outra causa possível desse erro:

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

(Reproduzido na instância do Ubuntu.)

para a ubuntu 12.04 lts micro instance eu tive que definir o nome de usuário como opção

ssh -i pemfile.pem -l ubuntu dns

Você precisa executar as seguintes etapas:

1. Abra seu cliente ou terminal ssh se você estiver usando Linux.
2. Localize seu arquivo de chave privada e altere seu diretório.
   cd <path to your .pem file>
3. Execute os comandos abaixo:
   chmod 400 <filename>.pem
ssh -i <filename>.pem ubuntu@<ipaddress.com>

Se o ubuntuusuário não estiver trabalhando, tente com ec2-user.

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

key_parse_private2: missing begin marker 

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

Usando o seguinte:

ssh -i ~/myKey.pem ec2-user@<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 a mensagem de depuração quatro linhas abaixo (acima) e fui enganado. Não há um problema com a chave, mas eu a 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, como 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.

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 a maneira correta era

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

Isso já aconteceu comigo várias vezes. Eu usei o Amazon Linux AMI 2013.09.2 e o Ubuntu Server 12.04.3 LTS, ambos no nível gratuito.

Toda vez que lancei uma instância, tenho permissão negada para aparecer. Não verifiquei isso, mas minha teoria é que o servidor não está completamente configurado antes de tentar fazer o ssh nele. Depois de algumas tentativas com permissão negada, espero alguns minutos e consigo me conectar. Se você está tendo esse problema, sugiro esperar cinco minutos e tentar novamente.

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

Se você estiver almoçando uma nova instância de uma AMI criada por outra instância (por exemplo, instância xyz), a nova instância aceitará apenas a mesma chave que a instância A usou. Isso é totalmente compreensível, mas fica confuso porque, durante o processo passo a passo da 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, apenas a chave que você estava usando, por exemplo, XYZ será aceita pela nova instância.

Eu lutei com isso por um tempo também até encontrar o seguinte:

eb ssh

Quando você usa isso no diretório do projeto, bingo-bango sem confusão, você está em

No meu próprio caso, fiz o seguinte:

chmod 400 <key.pem>

ssh -i <key.pem> ec2-user@ec2_public_dns (for debian)

Eu estava inicialmente usando root@parte e recebi este prompt:

Please login as the user "ec2-user" rather than the user "root".

Estou no Windows com WinSCP . Ele funciona muito bem no File Explorer e no PuTTY SSH Shell para acessar meu Amazon EC2-VPC Linux. Não há nada a ver com chmod pem fileo uso do myfile.ppk convertido por PuTTYgen a partir do arquivo pem .

A mesma coisa aconteceu comigo, mas tudo o que estava acontecendo é que a chave privada se perdeu do chaveiro na minha máquina local.

ssh-add -K

adicionou novamente a chave e, em seguida, o comando ssh para conectar retornou ao trabalho.

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

ssh -i ec2key.pem ubuntu@ec2-public-IP

Por duas vezes, as teclas e a linha de comando ssh estão corretas (sei porque estou duplicando uma instância do Ubuntu 14.04 em funcionamento), mas não consegui ssh em uma nova instância, mesmo depois de esperar 5 minutos, conforme sugerido por Wade Anderson acima.

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

Portanto, se você tiver esse problema, tente isso.

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 estar usando o nome de usuário correto, você pode tentar: 3.1. admin 3.2. usuário ec2 3.3. ubuntu

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

Minha chave privada foi configurada com permissão 400e resultou em Permissão negada definindo-a como '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 é obrigatório, ele não estava funcionando com 400

Quando você tenta fazer

ssh -i <.pem path> root@ec2-public-dns

Você recebe uma mensagem avisando que você deve usar o ec2-user.

Please login as the user "ec2-user" rather than the user "root".

Então use

ssh -i <.pem path> ec2-user@ec2-public-dns

Eu tive o mesmo problema e é muito estranho. Se você acredita que está fazendo tudo de bom, siga estas instruções: Algumas vezes há confusão sobre o usuário para a instância do EC2 !! Algumas vezes você recebe ec2-user, ubuntu, centos etc. Então verifique seu nome de usuário para ver o machie !!

Faça o login com o usuário root ssh -i yourkey.pem (400 permission) root@<ip> Irá gerar um erro e fornecerá o nome de usuário disponível . depois faça o login com esse usuário.

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

ssh -i ~/keys/<key_name> root@111.111.111.111

Mas foi outro usuário :

ssh -i ~/keys/<key_name> dedeco@111.111.111.111

Eu tive o mesmo erro, mas situação diferente. para mim, aconteceu do nada depois de muito tempo, eu consegui ssh com sucesso no meu computador remoto por aí. depois de muita pesquisa na solução do meu problema, havia permissões de arquivo. é estranho, é claro, porque eu não alterei nenhuma permissão no meu computador ou na remota pertencente aos arquivos / diretórios do ssh. então, a partir do bom wiki do archlinux, aqui está:

Para a máquina local, faça o seguinte:

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

Para a máquina remota, faça o seguinte:

$ 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).

Outro possível problema: ID de login incorreto

Marque 'Instruções de uso'

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

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 foi que a instância não foi iniciada corretamente devido a erro no script de execução na inicialização de Step 3: Configure instance detail emAdvanced details:

O que eu pensei ter inserido:

#include
 https://xxxx/bootstrap.sh


O que realmente entrou interrompe 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

É sensível a maiúsculas.

Errado: usuário SSH EC2 @ XXX.XX.XX.XX -i MyEC2KeyPair.pem

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

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

A maneira como eu descobri isso foi obtendo a chave pública da minha chave privada, assim:

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

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

Todas as respostas mais bem classificadas acima são precisas e devem funcionar na maioria dos casos. No caso de eles não funcionarem como no meu caso, simplesmente me livrei do meu ~/.ssh/known_hostsarquivo na máquina da qual estava tentando ssh e isso resolveu o problema para mim. Eu consegui me conectar depois.