Permissão SSH negada (publickey)

Question

Eu tentei pesquisar perguntas anteriores para obter respostas à minha pergunta, mas todas as respostas sugeridas anteriormente não funcionaram para mim.

Estou tentando conectar-me a um linode (executando o Ubuntu 12.04 LTS) da minha máquina local (também executando o ubnutu 12.04 LTS)

Eu criei uma chave privada e pública na minha máquina local e copiei minha chave pública para o arquivo authorized_keys do meu linode. No entanto, sempre que eu tento usar o ssh no meu linode, recebo a mensagem de erro "Permission denied (publickey).

Não é um problema com o modo como o ssh é configurado no meu linode porque eu posso ssh para ele da minha máquina Windows usando autenticação de chave.

No meu diretório .ssh na minha máquina local do ubuntu eu tenho meus arquivos id_rsa e id_rsa.pub. Preciso criar um arquivo authorized_keys na minha máquina local?

EDIT: Isto é o que eu recebo quando eu corro ssh -vvv -i id_rsa [youruser] @ [yourLinode]

debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey).

    

Answer 1

PubKeyAuthentication

Configure seu cliente

1. Gerar sua chave
   • ssh-keygen
2. Configurar o ssh para usar a chave
   • vim ~/.ssh/config
3. Copie sua chave para seu servidor
   • ssh-copy-id -i /path/to/key.pub SERVERNAME

Seu arquivo de configuração da etapa 2 deve ter algo semelhante ao seguinte:

Host SERVERNAME
Hostname ip-or-domain-of-server
User USERNAME
PubKeyAuthentication yes
IdentityFile ./path/to/key

Solução de problemas

1. use a opção "-vvv"
2. Certifique-se de que o servidor tenha sua chave PUBLIC (.pub).
3. Verifique se o seu IdentiyFile aponta para sua chave particular.
4. Certifique-se de que seu diretório .ssh tenha 700 e seus arquivos tenham 700 permissões (rwx ------).
5. tail -f /var/log/auth.log (no servidor) e monitora erros quando você tenta efetuar login

Answer 2

Às vezes, o problema é proveniente de permissões e propriedade. Por exemplo, se você quiser efetuar login como raiz, /root , .ssh e authorized_keys devem pertencer ao root. Caso contrário, o sshd não poderá lê-los e, portanto, não poderá dizer se o usuário está autorizado a efetuar login.

No seu diretório pessoal:

chown -R your_user:your_user .ssh

Quanto aos direitos, vá com 700 para .ssh e 600 para authorized_keys

chmod 700 .ssh
chmod 600 .ssh/authorized_keys

    

Answer 3

Você não precisa de authorized_keys no seu cliente.

Você deve dizer ao ssh-client para realmente usar a chave que você gerou. Existem várias maneiras de fazer isso. Apenas para testar o tipo ssh -vvv -i .ssh/id_rsa [youruser]@[yourLinode] . Você terá que fornecer sua frase toda vez que quiser se conectar ao servidor.

Se isso funcionou, você pode adicionar a chave ao ssh-agent com ssh-add .ssh/id_rsa (você terá que fornecer a senha apenas uma vez para isso e ela deverá funcionar contanto que você não efetue logout / reinicialização)

    

Answer 4

Certifique-se também de que o diretório pessoal do usuário (no servidor) realmente pertence ao usuário ssh'ing (foi definido como root: root no meu caso).

Deveria ter sido:

sudo chown username:username /home/username;

    

Answer 5

O problema que tive foi que estava usando as chaves erradas no cliente. Eu tinha renomeado id_rsa e id_rsa.pub para outra coisa. Você pode renomeá-los de volta ao seu padrão, ou quando você emite o comando ssh, use-o como este

ssh -i ~/.ssh/private_key username@host

    

Answer 6

Verifique também o valor de PasswordAuthentication em /etc/ssh/sshd_config e se é no altere para yes . Não esqueça de reiniciar o serviço ssh depois disso.

    

Answer 7

Encontrei esse problema recentemente com meu servidor da Web.

Eu normalmente mantenho uma lista de chaves autorizadas em todos os meus servidores em ~/.ssh/authorized_keys2 . Da minha experiência, sshd procurará ~/.ssh/authorized_keys ou ~/.ssh/authorized_keys2 por padrão.

No caso do meu servidor, o /etc/ssh/sshd_config tinha essa linha

AuthorizedKeysFile    %h/.ssh/authorized_keys

em vez de

AuthorizedKeysFile    %h/.ssh/authorized_keys2

Eu apliquei o último, reiniciei meu daemon ssh e resolvi meu problema fazendo login com o ssh usando meu pubkey.

    

Answer 8

Isso é o que funcionou para mim, a correção não é minha, mas eu prefiro escrevê-la aqui no caso de alguém ter o mesmo problema.

O autor original postou aqui: digital-ocean -chave de acesso público negado

sudo nano /etc/ssh/sshd_config

Substitua isto

UsePAM yes
IgnoreUserKnownHosts no
PasswordAuthentication no

Com isso

UsePAM no
IgnoreUserKnownHosts no
PasswordAuthentication yes

Salve o arquivo e reinicie o ssh

reload ssh

ssh deve funcionar agora pedindo uma senha

    

Answer 9

Eu meu caso, o cliente é 14.04lts do Ubuntu, o servidor foi ganhar 2012 servidor executando cygwin. Eu estava usando 'ssh [email protected]', quando o diretório do servidor 2012 no cygwin era / home / Administrator. Por isso, era sensível a maiúsculas e minúsculas, quando tentei 'ssh [email protected]' (note a maiúscula A em Administrador) então funcionou bem.

Uma mensagem de erro como 'usuário não encontrado' teria me levado à solução muito mais rápido do que 'Permissão negada (publickey, keyboard-interactive)'.

    

Answer 10

Eu tive o mesmo problema ao copiar uma chave pública de um usuário regular (por exemplo, johndoe) de um sistema cPanel Centos para um servidor Ubuntu na AWS. Como sugerido por gertvdijk acima, eu verifiquei /var/log/auth.log e com certeza ele disse Authentication refused: bad ownership or modes for directory /home/johndoe . Acontece que eu tinha incorretamente 777'ed /home/johndoe ao tentar definir /home/johndoe/public_html como o padrão virtualhost Document Root para apache2 (que não é necessário para essa tarefa também).

Veja também as respostas aqui e here

O servidor só precisa ter a chave pública em .ssh/authorized_keys e o cliente (o computador no qual você está trabalhando) precisa ter a chave privada (.pem ou, se estiver usando SFTP com o Filezilla, .ppk)

    

Answer 11

Para aqueles usuários do Putty como eu que vieram a este tópico, você também pode receber este erro se você esqueceu de adicionar o usuário @ Ip!

Outros sendo permissão no arquivo-chave chmod para 600)

ssh 1.1.1.1 -i /path/to/.pem file 
Permission denied (publickey).'

ssh [email protected] -i /path/to/.pem file 

    

Answer 12

Eu tive o mesmo problema descrito na pergunta. A saída da execução de ssh -vvv -i id_rsa [youruser]@[yourLinode] na máquina cliente foi semelhante à descrita na pergunta. Verifiquei todas as permissões de arquivos e diretórios, conforme recomendado nas outras respostas, e elas estavam corretas.

Descobrimos que, ao copiar o arquivo gerado id_rsa.pub para a máquina do servidor, como o arquivo ~username/.ssh/authorized_keys , acidentalmente omiti a palavra ssh-rsa desde o início. Adicioná-lo foi resolvido o problema.

    

Answer 13

Se tudo mais falhar, verifique se o seu usuário de login pertence ao AllowedGroup do ssh. Ou seja, seus usuários são membros do grupo mostrado na linha a seguir em /etc/ssh/sshd_config no servidor:

AllowGroups ssh #Here only users of 'ssh' group can login

    

Answer 14

Outra possível causa pode estar na configuração AllowedUsers em /etc/ssh/sshd_conf . NOTA: a lista é espaço delimitada (não delimitada por vírgulas) conforme aprendi da maneira mais difícil.

AllowUsers user1 user2 user3

    

Answer 15

No meu caso, o problema foi causado pela cópia em um diretório .ssh de uma máquina mais antiga. Acontece que minha configuração SSH mais antiga estava usando chaves DSA que, desde então, foram obsoletas . Mudar para um novo par de chaves, desta vez baseado em RSA, resolveu o problema para mim.

    

Answer 16

O método a seguir pode funcionar se você puder acessar machineA e machineB independentemente (por exemplo, de machineC).

Se o ssh-copy-id não estiver funcionando, a autenticação de senha poderá ser desativada. A seguir, uma solução alternativa .

Ter a chave pública da máquinaA nas chaves autorizadas da máquinaB (por exemplo, ~ / .ssh / authorized_keys) permitirá que você faça o ssh da máquinaA. Isso também se aplica ao scp.

Depois de gerar os pares de chaves usando: ssh-keygen

Em machineA , execute cat ~/.ssh/id_rsa.pub

Exemplo de saída:

  

ssh-rsa AAAAB3NzaSGMFZW7yB anask@mahineA

Copie a chave impressa ( ⌘ Comando + C ou CRTL + C ) e adicione-a o arquivo ~ / .ssh / authorized_keys no machineB .

Por exemplo, execute o seguinte em machineB :

  

echo 'ssh-rsa AAAAB3NzaSGMFZW7yB anask@mahineA' >> ~/.ssh/authorized_keys