ti-enxame.com

Por que obtenho "Permissão negada (chave pública)" ao tentar fazer o SSH do Ubuntu local para um servidor Amazon EC2?

Eu tenho uma instância de um aplicativo em execução na nuvem na instância do Amazon EC2 e preciso conectá-lo no meu Ubuntu local. Ele funciona bem em um dos locais Ubuntu e também laptop. Recebi a mensagem "Permissão negada (chave pública)" ao tentar acessar o SSH no EC2 em outro Ubuntu local. É tão estranho para mim.

Estou pensando em algum tipo de problema com as configurações de segurança no Amazon EC2, que limitou o acesso de IPs a uma instância ou certificado.

Alguém sabe uma solução?

217
Vorleak Chy

A primeira coisa a fazer nessa situação é usar o -v opção para ssh, para que você possa ver quais tipos de autenticação são tentados e qual é o resultado. Isso ajuda a esclarecer a situação?

Na atualização da sua pergunta, você menciona "em outro Ubuntu local". Você copiou a chave privada ssh para a outra máquina?

143
Greg Hewgill

Como não foi mencionado explicitamente, o sshd é, por padrão, muito rígido quanto às permissões dos arquivos authorized_keys. Portanto, se authorized_keys For gravável para alguém que não seja o usuário ou puder ser gravado por alguém que não seja o usuário, ele se recusará a se autenticar ( a menos que o sshd esteja configurado com StrictModes no)

O que eu quero dizer com "pode ​​ser tornado gravável" é que, se qualquer um dos diretórios pai for gravável para alguém que não seja o usuário, os usuários com permissão para modificar esses diretórios poderão começar a modificar as permissões de forma que possam modificar/substituir as autorizadas.

Além disso, se o diretório /home/username/.ssh Não for de propriedade do usuário e, portanto, o usuário não tiver permissões para ler a chave, você poderá encontrar problemas:

drwxr-xr-x 7 jane jane 4096 Jan 22 02:10 /home/jane
drwx------ 2 root root 4096 Jan 22 03:28 /home/jane/.ssh

Observe que Jane não possui o arquivo .ssh. Corrija isso via

chown -R jane:jane /home/jane/.ssh

Esses tipos de problemas de permissão do sistema de arquivos não aparecerão com ssh -v E nem aparecerão nos logs sshd (!) Até que você defina o nível de log como DEBUG.

  • Edite /etc/ssh/sshd_config. Você quer uma linha que leia LogLevel DEBUG Lá em algum lugar. Recarregue o servidor SSH usando o mecanismo fornecido pela distribuição. (service sshd reload No RHEL/CentOS/Scientific.) Uma recarga normal não interrompe as sessões existentes.
  • Tente se autenticar novamente.
  • Descubra onde seus logs do recurso de autenticação vão e os leia. (IIRC, /var/log/auth.log Nas distribuições baseadas no Debian; /var/log/secure No RHEL/CentOS/Scientific.)

Muito mais fácil descobrir o que está errado com a saída de depuração, que inclui erros de permissão do sistema de arquivos. Lembre-se de reverter a alteração para /etc/ssh/sshd_config Quando terminar!

76
Kjetil Joergensen

Eu recebi esse erro porque esqueci de adicionar -l opção. Meu nome de usuário local não era o mesmo que no sistema remoto.

Isso não responde à sua pergunta, mas cheguei aqui procurando uma resposta para o meu problema.

37
pkmk

Recebi esta mensagem em uma nova instância baseada na AMI do Ubuntu. Eu estava usando a opção -i para fornecer o PEM, mas ele ainda estava mostrando a "Permissão negada (chave pública)".

Meu problema era que eu não estava usando o usuário correto. Ao executar o ssh com o ubuntu @ ec2 ... funcionou normalmente.

19
user60587

Algo mais fácil de ler do que ssh -v (na minha opinião, é claro), é tail -f /var/log/auth.log. Isso deve ser executado no servidor ao qual você está tentando se conectar, enquanto tenta se conectar. Ele mostrará erros em texto sem formatação.

Isso me ajudou a resolver meu problema:

Usuário [nome de usuário] de xx.yy.com não permitido, porque nenhum dos grupos de usuários está listado em AllowGroups

16
Znarkus

Verifique seu arquivo / etc/ssh/sshd_config. Lá, encontre a linha que diz

PasswordAuthentication no

Essa linha precisa ser modificada para dizer sim em vez de não. Além disso, reinicie o servidor sshd posteriormente.

Sudo /etc/init.d/ssh restart
10
Sudipta Chatterjee

Talvez não seja relevante para o pôster atual, mas pode ajudar outras pessoas que o encontrarem ao procurar respostas para situações semelhantes. Em vez de permitir que a Amazon gere o par de chaves ssh, recomendo carregar sua própria chave ssh pública padrão e padrão na Amazon e especificar isso quando você executar uma instância do EC2.

Isso permite que você descarte a sintaxe do tipo "-i" no ssh, use o rsync com opções padrão e também use a mesma chave ssh em todas as regiões do EC2.

Eu escrevi um artigo sobre esse processo aqui:

Carregamento de chaves ssh pessoais no Amazon EC2
http://alestic.com/2010/10/ec2-ssh-keys

6
Eric Hammond

Estranhamente, meu problema acabou sendo o servidor ter sido reiniciado e ter recebido um novo nome DNS. Eu estava usando o nome DNS antigo. Eu sei que isso soa estúpido, mas levei um tempo para descobrir isso.

5
Patrick Collins

Se você estiver tentando se conectar a um telefone CyanogenMod executando o Dropbear, execute as seguintes linhas para garantir que tudo esteja com permissão correta:

chmod 600 /data/dropbear/.ssh/authorized_keys

ou

chmod 700 /data/dropbear/.ssh/authorized_keys # In case of MacOS X 10.6-10.8

e

chmod 755 /data/dropbear/ /data/dropbear/.ssh

Isso corrigiu para mim, caso contrário, nada pode se conectar.

2
Naftuli Kay

Se você estiver usando o CentOS 5, convém definir StrictModes no no /etc/ssh/sshd_config. Estou compartilhando o diretório/home usando NIS/NFS e defino todas as permissões corretamente, mas sempre me solicitava a senha. Depois de definir StrictModes no, o problema desapareceu!

2
uichin

Eu estava tendo o mesmo problema, embora estivesse supostamente seguindo todas as etapas, incluindo

$ ec2-authorize default -p 22

No entanto, eu havia iniciado minha instância na região us-west-1. Portanto, o comando acima também deve especificar isso.

$ ec2-authorize default -p 22 --region us-west-1

Após esse comando, pude fazer o ssh na instância. Passei um pouco antes de perceber o problema e espero que este post ajude outras pessoas.

1
Ajit Verma

A resposta de Greg explica como resolver problemas de maneira melhor, no entanto, o problema real é que você tem uma chave ssh definida em um lado da transação (o cliente), que está tentando autenticação de chave pública em vez de autenticação baseada em senha. Como você não possui a chave pública correspondente na instância do EC2, isso não funcionará.

1
Cian

Eu tive o mesmo problema e, depois de tentar várias soluções que não funcionaram, abri a porta SSH no firewall do meu roteador (o painel de controle do firewall do roteador está uma bagunça, por isso é difícil dizer o que está acontecendo). De qualquer forma, isso corrigiu :)

Super irritante que o erro que você recebe seja Permissão Negada, implicando que houve algum tipo de conexão feita, grr.

1
chichilatte

Acabei de experimentar o mesmo problema depois de adicionar inadvertidamente permissões de gravação de grupo ao diretório inicial dos usuários.

Eu descobri que essa era a causa executando tail -f /var/log/secure na máquina e vendo o erro Authentication refused: bad ownership or modes for directory /home/<username>.

0
Jacob Tomlinson

Este é um caso raro, mas se você tiver o selinux ativado e estiver usando o nfs para o diretório com as chaves_computadas (por exemplo, diretórios pessoais compartilhados), será necessário desativar o selinux (não recomendado por razões de segurança, mas você pode temporariamente desabilitá-lo). para ver se isso está causando o problema) ou permita que o selinux use os diretórios pessoais do nfs. Não tenho certeza dos detalhes, mas isso funcionou para mim setsebool -P use_nfs_home_dirs 1

0
Reese