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 ubuntu locais e também laptop. Recebi a mensagem "Permissão negada (publickey)" ao tentar acessar o SSH para o 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, o qual o acesso limitado de IPs a uma instância ou certificado pode precisar gerar novamente.
Alguém conhece uma solução?
A primeira coisa a fazer nessa situação é usar a opção -v para ssh , para que você possa ver que tipos de autenticação são tentados e qual é o resultado. Isso ajuda a esclarecer a situação?
Na 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 mencionado explicitamente, o sshd é, por padrão, muito restrito às permissões dos arquivos authorized_keys . Portanto, se authorized_keys for gravável para qualquer um que não 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 seja configurado com StrictModes no )
O que quero dizer com "pode ser feito gravável" é que se qualquer um dos diretórios pai for gravável para qualquer um além do usuário, os usuários autorizados a modificar esses diretórios poderão começar a modificar permissões de forma que possam modificar / substituir authorized_keys.
Isso não será exibido com ssh -v , ele será exibido nos registros emitidos pelo sshd (normalmente, colocar em /var/log/secure ou /var/log/auth.log , depende da configuração de distro e syslogd ).
De man sshd (8):
~/.ssh/authorized_keys
Lists the public keys (RSA/DSA) that can be used for logging in
as this user. The format of this file is described above. The
content of the file is not highly sensitive, but the recommended
permissions are read/write for the user, and not accessible by
others.
If this file, the ~/.ssh directory, or the user's home directory
are writable by other users, then the file could be modified or
replaced by unauthorized users. In this case, sshd will not
allow it to be used unless the StrictModes option has been set to
“no”.
Recebi este erro porque esqueci de adicionar a opção -l . Meu nome de usuário local não era o mesmo que no sistema remoto.
Isso não responde à sua pergunta, mas eu cheguei aqui procurando uma resposta para o meu problema.
Eu recebi esta mensagem em uma nova instância baseada no Ubuntu AMI. Eu estava usando a opção -i para fornecer o PEM, mas ainda estava mostrando a "Permissão negada (publickey)".
Meu problema é que eu não estava usando o usuário correto. Ao executar o ssh com o ubuntu @ ec2 ... funcionou normalmente.
Algo mais fácil de ler do que ssh -i (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:
User [username] from xx.yy.com not allowed because none of user's groups are listed in 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 depois.
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 o upload de sua chave ssh pública padrão e padrão para a Amazon e especificar que, quando você executar uma instância do EC2.
Isso permite que você solte a sintaxe do tipo "-i" em 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:
Uploading Personal ssh Keys to Amazon EC2
http://alestic.com/2010/10/ec2-ssh-keys
Estranhamente, meu problema era que o servidor havia sido reiniciado e foi emitido um novo nome DNS. Eu estava usando o antigo nome DNS. Eu sei que isso soa estúpido, mas levei um tempo para entender isso.
Se você estiver tentando se conectar a um celular CyanogenMod executando o Dropbear, execute as seguintes linhas para ter certeza de que tudo está correto:
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 consertou isso para mim, caso contrário, nada pode se conectar.
Se você estiver usando o CentOS 5, talvez queira definir StrictModes no em /etc/ssh/sshd_config . Estou compartilhando o diretório / home usando o NIS / NFS, e configurei todas as permissões corretamente, mas sempre solicito a senha. Depois de definir StrictModes no , o problema desapareceu!
A resposta de Greg explica como solucionar o problema melhor, mas o problema é que você tem um conjunto de chaves ssh 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 tem a chave pública correspondente na instância do EC2, isso não funcionará.
Eu tive o mesmo problema, e depois de tentar várias soluções que não funcionaram, eu abri a porta SSH no firewall do meu roteador (o painel de controle do meu roteador está uma bagunça, então é difícil dizer o que está acontecendo). Enfim, isso resolveu:)
Super muito chato que o erro que você recebe é Permission Denied, implicando que houve algum tipo de conexão, grr.
Eu estava tendo o mesmo problema, apesar de eu estar seguindo todos os passos incluindo
$ ec2-authorize default -p 22
No entanto, eu havia iniciado minha instância na região us-west-1. Portanto, o comando acima deve também especifique isso.
$ ec2-authorize default -p 22 --region us-west-1
Após esse comando, consegui fazer ssh na instância. Passei um pouco antes Eu percebi o problema e espero que este post ajude os outros.
Este é um caso raro, mas se você tiver o selinux habilitado e estiver usando o nfs para o diretório com o authorized_keys (por exemplo, diretórios home compartilhados), você precisará desabilitar 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 permitir que o selinux use os diretórios home do nfs. Eu não estou claro sobre os detalhes, mas isso funcionou para mim
setsebool -P use_nfs_home_dirs 1
Acabei de passar pelo mesmo problema depois de adicionar inadvertidamente permissões de gravação de grupo ao diretório inicial dos usuários.
Descobri que esta 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> .