Problema 'Acesso permissível negado (chave pública)' do AWS ssh [fechado]

284

Como se conectar a uma instância da AWS através do ssh?

Eu tenho:

  1. Inscreveu-se na AWS;
  2. Criou uma chave pública e um certificado no site da AWS e os salvou em disco;

  3. Fui ao meu console e criei variáveis ​​de ambiente: 

    $ export JAVA_HOME=/usr/lib/jvm/java-6-openjdk/
$ export EC2_CERT=/home/default/aws/cert-EBAINCRNWHDSCWWIHSOKON2YWGJZ5LSQ.pem
$ export EC2_PRIVATE_KEY=/home/default/aws/pk-EBAINCRNWHDSCWWIHSOKON2YWGJZ5LSQ.pem

  4. Disse à API da AWS para usar esse par de chaves e salvou o par de chaves no arquivo: 

    $ ec2-add-keypair ec2-keypair > ec2-keypair.pem

  5. Iniciou uma instância do AWS Ubuntu 9 usando este par de chaves: 

    $ ec2-run-instances ami-ed46a784 -k ec2-keypair

  6. Tentativa de estabelecer uma conexão ssh com a instância: 

    $ ssh -v -i ec2-keypair.pem ubuntu@ec2-174-129-185-190.compute-1.amazonaws.com
OpenSSH_5.1p1 Debian-5ubuntu1, OpenSSL 0.9.8g 19 Oct 2007
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to ec2-174-129-185-190.compute-1.amazonaws.com [174.129.185.190] port 22.
debug1: Connection established.
debug1: identity file ec2-keypair.pem type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.1p1 Debian-5ubuntu1
debug1: match: OpenSSH_5.1p1 Debian-5ubuntu1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.1p1 Debian-5ubuntu1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc 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-174-129-185-190.compute-1.amazonaws.com' is known and matches the RSA host key.
debug1: Found key in /home/default/.ssh/known_hosts:11
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: ec2-keypair.pem
debug1: read PEM private key done: type RSA
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.
Permission denied (publickey).

    Qual poderia ser o problema e como fazê-lo funcionar?

amazon-web-services  ssh-keys 
— Alex
fonte
2
Irônico é que eu uso "root" como nome de usuário, mas "ubuntu" (o que você mencionou) é o nome certo para minha AMI, e obrigado por sua postagem!
— realjin
— CtheGood

Respostas:

512

Para instâncias do Ubuntu:

chmod 600 ec2-keypair.pem
ssh -v -i ec2-keypair.pem ubuntu@ec2-174-129-185-190.compute-1.amazonaws.com

Para outras instâncias, você pode ter que usar em ec2-uservez de ubuntu.

A maioria das imagens do EC2 Linux que usei têm apenas o usuário root criado por padrão.

Veja também: http://www.youtube.com/watch?v=WBro0TEAd7g

— sipwiz
fonte
6
Você é demais! Tão malditamente simples!
— Alex
50
Você também pode usar ssh-add ec2-keypair.pem assim você pode soltar a opção -i
— AdamK
12
se você tentar o root e obtiver "Por favor, faça o login como usuário do ec2 em vez de usuário root". use ec2-user no lugar do root.
— Tony
8
E algumas imagens do Ubuntu parecem ter apenas o usuário "ubuntu". (O que pode sudo fazer root.)
— O contrato do Prof. Falken violou
1
Super, super útil.
— NSCoder
93

Agora é:

ssh -v -i ec2-keypair.pem ec2-user@[yourdnsaddress]
— SSH
fonte
Obrigado. Levei séculos para descobrir isso - não é mencionado nas informações de conexão do console! Ele diz quando você tenta usar o root, mas achei que ec2-user era uma referência ao meu nome de usuário. Doh!
— Adrian Mouat
1
Oh cara. Não é um petisco fácil de encontrar. Obrigado!
— precisa saber é
Obrigado, não é fácil ti encontrar este
Muito bom! Obrigado!
— Viana
46

As versões da Canonical usam o usuário 'ubuntu' por padrão para qualquer pessoa que chegue aqui com uma imagem do ubuntu que está apresentando o mesmo problema.

— Bryon
fonte
2
Não é fácil encontrar este.
— Gustav
17

Se você estiver usando uma imagem Bitnami, faça o login como 'bitnami'.

Parece óbvio, mas algo que eu esqueci.

— akim
fonte
Sua resposta salvou meu dia!
— Surya
2
Você quis dizer? Seems <sarcasm>obvious</sarcasm>
— Bob Stein
Instruções Bitnami , incluindo como encontrar as senhas do banco de dados.
— 9789 Bob Stein
8

Para minhas imagens do ubuntu, na verdade é o usuário do ubuntu e NÃO o usuário do ec2;)

— Dean Hiller
fonte
5

Ele também reclamará se as permissões do arquivo pem estiverem muito abertas. chmod o arquivo para 600 para corrigir isso.

— Allan Bogh
fonte
Obrigado por esta dica - me ajudou muito
— Billy Lua
4
Para iniciantes .. o comando para fazer isso seria:chmod 600 your_file.pem
— dano 28/01
5

Eu também estava pensando nisso - acontece que estava usando uma AMI criada pela comunidade - e o nome de usuário padrão não era mais o root, nem o ect-user ou o ubuntu. Na verdade, eu não tinha ideia do que era - até que tentei ' root ' e o servidor gentilmente me pediu para entrar como xxx, onde xxx é o que quer que seja.

-Felicidades!

— kevinfoundananswwer
fonte
4

Você precisa ter sua chave privada em sua máquina local

Você precisa saber o endereço IP ou o nome DNS da sua máquina ou servidor remoto. Você pode obter isso no console da AWS

Se você é um usuário Linux

  • Verifique se as permissões na chave privada são 600 ( chmod 600 <path to private key file>)
  • Conecte-se à sua máquina usando ssh ( ssh -i <path to private key file> <user>@<IP address or DNS name of remote server>)

Se você é um usuário do Windows

— Vineeth Guna
fonte
Altere a permissão do arquivo usando chmod 400 <chave pem>
— Vaibhav Jain 2/16
3

usar... 

# chmod 400 ec2-keypair.pem

não use a permissão 600, caso contrário você poderá sobrescrever sua chave acidentalmente.

— x1b2j
fonte
2

isso funcionou para mim:

ssh-keygen -R <server_IP>

excluir as chaves antigas armazenadas na estação de trabalho também funciona em vez de

então fazendo o mesmo ssh novamente funcionou:

ssh -v -i <your_pem_file> ubuntu@<server_IP>

nas instâncias do ubuntu, o nome de usuário é: ubuntu on Amazon Linux AMI, o nome de usuário é: ec2-user

Não tive que recriar a instância a partir de uma imagem.

— Cris
fonte
2

Existem 2 etapas a serem conectadas:

Chmod 400 na sua chave privada, assim os outros não podem acessar a sua chave:

chmod 400 toto.pem

Para se conectar à sua instância no SSH, você precisa saber o endereço IP público da sua instância: 

ssh -i toto.pem ec2-user@XX.XX.XX.XXX

Espero que ajude !

— GuillaumeAgis
fonte
1

Se você estiver usando o EBS, também poderá tentar montar o volume do EBS em uma instância em execução. Em seguida, monte-o nessa instância em execução e veja o que está acontecendo em / home. Você pode ver coisas como é o usuário ubuntu ou ec2-user? ou possui as chaves públicas corretas em ~ / .ssh / allowed_keys

— Rico
fonte
1

A permissão para ec2-keypair.pemdeve ser400

chmod 400 ec2-keypair.pem

— Yogi
fonte
1

Se você estiver executando a imagem da AWS no Bitnami. O nome de usuário seria bitnami. Felicidades!

veja meu debug e olhe o último:

*

ssh -v -i awsliferaysrta.pem.txt root@54.254.250.***
OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011
debug1: Reading configuration data /etc/ssh_config
debug1: /etc/ssh_config line 20: Applying options for *
debug1: Connecting to 54.254.250.*** [54.254.250.***] port 22.
debug1: Connection established.
debug1: identity file awsliferaysrta.pem.txt type -1
debug1: identity file awsliferaysrta.pem.txt-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.2
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9p1 Debian-5ubuntu1.1
debug1: match: OpenSSH_5.9p1 Debian-5ubuntu1.1 pat OpenSSH_5*
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: Server host key: RSA 05:5c:78:45:c9:39:3a:84:fe:f8:19:5d:31:48:aa:5f
debug1: Host '54.254.250.***' is known and matches the RSA host key.
debug1: Found key in /Users/macbookpro/.ssh/known_hosts:2
debug1: ssh_rsa_verify: signature correct
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: Trying private key: awsliferaysrta.pem.txt
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).
Authenticated to 54.254.250.*** ([54.254.250.***]:22).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: Remote: Port forwarding disabled.
debug1: Remote: Agent forwarding disabled.
debug1: Remote: X11 forwarding disabled.
debug1: Remote: Forced command.
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8
Please login as the user "bitnami" rather than the user "root".

*

— Hung Do
fonte
1

No meu caso (Mac OS X), o problema era o tipo de interrupção do arquivo. Tente o seguinte:

1.- Abra o arquivo .pem com o TextWrangler

2.- Na parte inferior do aplicativo, verifique se o tipo de quebra é "Windows (CRLF)".

— pmartinezd
fonte
1

Seu usuário ec2 para imagens da Amazon Linux AMI e ubuntu para Ubuntu. Além disso, RHEL 6.4 e mais recente usuário ec2 RHEL 6.3 e raiz anterior Centos root do Fedora ec2-usuário

— Amith Ajith
fonte
0

Apenas adicionando a esta lista. Esta manhã, eu estava com problemas com um novo usuário adicionado a uma instância do AWS EC2. Para ir direto ao ponto, o problema era o selinux (que estava em impor modo de ), junto com o fato de que meu diretório pessoal do usuário estava em um novo volume anexado ao EBS. De alguma forma, acho que o selinux não gosta desse outro volume. Demorei um pouco para descobrir, enquanto eu examinava todos os outros problemas ssh comuns (/ etc / ssh / sshd_config estava bom, é claro que nenhuma senha permitida, permissões estavam corretas etc.)

O conserto?

Por enquanto (até que eu entenda como permitir que um usuário faça ssh para um volume diferente ou, de alguma forma, torne esse volume um ponto de diretório doméstico genuíno):

sudo perl -pi -e 's/^SELINUX=enforcing/SELINUX=permissive/' /etc/selinux/config
sudo setenforce 0

É isso aí. Agora meu novo usuário pode efetuar login, usando sua própria chave id_rsa.

— Pierre D
fonte
0

Teve o mesmo problema. Permissão negada (publickey) ao tentar efetuar login com 'ec2-user' ou com 'root'.

Pesquisou o número AMI da imagem da máquina e tinha as informações de login do SSH diretamente na página wiki da Debian.

Espero que isto ajude.

— Lionel Morrison
fonte
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.