amazon web services - with - Permissão negada(publickey) quando o acesso SSH à instância do Amazon EC2
permission denied aws ec2 (20)
Eu quero usar minha instância do Amazon ec2, mas enfrentei o seguinte erro:
Permission denied (publickey).
Eu criei meu par de chaves e baixei o arquivo .pem .
Dado:
chmod 600 pem file.
Então, esse comando
ssh -i /home/kashif/serverkey.pem [email protected]
Mas tem esse erro:
Permission denied (publickey)
Além disso, como posso me conectar com o filezilla para fazer upload / download de arquivos?
É 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:
- Acesso ao Console de gerenciamento da AWS
- Guia Open Elastic Beanstalk
- Selecione seu aplicativo na guia Todas as Aplicações
- Do lado esquerdo menu selecione Configuração
- Clique no botão Instances Gear
- 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.
- Salve
- 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.
- Acesso ao Console de gerenciamento da AWS
- Abrir guia do EC2
- Na lista Instâncias, selecione a instância na qual você está interessado
- Na guia Descrição, digite o nome do grupo de segurança que sua instância está usando.
- 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
- Se não, em Network & Security menù selecione Security Group
- Selecione o grupo de segurança usado por sua instância e clique na guia Entrada
- À 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.
- Clique em Add Rule e, em seguida, Apply Your Changes
- 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:
- Verifique se o seu endereço IP está correto
- Verifique se você está usando a chave correta
- 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.