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

A primeira coisa a fazer nessa 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?

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

Como não foi explicitamente mencionado, o sshd é, por padrão, muito rigoroso nas permissões dos authorized_keysarquivos. Portanto, se authorized_keysfor gravável para qualquer pessoa que não seja o usuário ou puder ser gravável por qualquer pessoa que não seja o usuário, ele se recusará a autenticar (a menos que sshd esteja configurado com StrictModes no)

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

Além disso, se o /home/username/.sshdiretório não for de propriedade do 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 com ssh -v, e eles 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 leia LogLevel DEBUGem algum lugar. Recarregue o servidor SSH usando o mecanismo fornecido pela distribuição. ( service sshd reloadno RHEL/CentOS/Scientific.) Um recarregamento normal não irá 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 distribuições 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!

Recebi este erro, porque esqueci de adicionar a -lopçã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.

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 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 ubuntu@ec2... funcionou normalmente.

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:

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

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

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

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

Eu escrevi um artigo sobre esse processo aqui:

Fazendo upload de chaves ssh pessoais para o Amazon EC2
http://alestic.com/2010/10/ec2-ssh-keys

Estranhamente, meu problema acabou sendo que o servidor foi reiniciado e foi emitido um novo nome DNS. Eu estava usando o nome DNS antigo. Eu sei que isso parece estúpido, mas demorei um pouco para descobrir isso.

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

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.

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