☰

Permissão negada (chave pública). SSH do Ubuntu local para o servidor Amazon EC2

tag-icon • tag-icon linux ssh amazon-ec2
Permissão negada (chave pública). SSH do Ubuntu local para o servidor Amazon EC2

Tenho uma instância de um aplicativo em execução na nuvem em uma instância do Amazon EC2 e preciso me conectar a ela no Ubuntu local. Funciona bem em um Ubuntu local e também em um laptop. Recebi esta mensagem, Permission denied (publickey).ao tentar fazer SSH para EC2 de umdiferenteUbuntu local.

Estou pensando que pode haver problemas com as configurações de segurança no Amazon EC2, que limitou o acesso IP a uma instância; ou talvez um certificado precise ser regenerado.

Alguém conhece uma solução para o erro de permissão negada?

Responder1

A primeira coisa a fazer nesta situação é usar a -vopçã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?

Responder2

Como não foi mencionado explicitamente, o sshd é, por padrão, muito rigoroso quanto às permissões dos authorized_keysarquivos. Então, se authorized_keysforgravávelpara qualquer pessoa que não seja o usuário oupode ser tornado gravávelpor qualquer pessoa que não seja o usuário, ele se recusará a autenticar (a menos que o sshd esteja configurado com StrictModes no)

O que quero dizer com "pode ​​ser gravável" é que, se algum dos diretórios pai for gravável para qualquer pessoa 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 chaves_autorizadas.

Além disso, se o /home/username/.sshdiretório não pertencer ao usuário e, portanto, o usuário não tiver permissão para ler a chave, você poderá ter 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 .ssharquivo. Corrija isso através

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

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

  • Editar /etc/ssh/sshd_config. Você quer uma linha que esteja escrita LogLevel DEBUGem algum lugar. Recarregue o servidor SSH usando o mecanismo fornecido pela distro. ( service sshd reloadno RHEL/CentOS/Scientific.) Uma recarga elegante não eliminará as sessões existentes.
  • Tente autenticar novamente.
  • Descubra para onde vão os logs do seu recurso de autenticação e leia-os. (IIRC, /var/log/auth.logem distros baseadas em Debian; /var/log/secureem 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_configquando terminar!

Responder3

Recebi este erro porque esqueci de adicionar -la opção. Meu nome de usuário local não era o mesmo do sistema remoto.

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

Responder4

Algo que é 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 simples.

Isso me ajudou a resolver meu problema:

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

informação relacionada