ssh-copy-id não funciona

Question

Estou tentando configurar um login SSH sem senha no CentOS 5.4:

1. Gerei uma chave pública RSA no cliente.
2. ssh-copy-id do cliente para o servidor.
3. Verificado ~ / .ssh / authorized_keys contém a chave do cliente.

O cliente ainda solicita a senha. O que eu senti falta?

Obrigado.

EDIT: verificado ssh_config e permissões, conforme recomendado. Esta é a informação de depuração do cliente:

debug2: key: /home/saguna/.ssh/identity ((nil))
debug2: key: /home/saguna/.ssh/id_rsa (0x2b31921be9a0)
debug2: key: /home/saguna/.ssh/id_dsa ((nil))
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug3: start over, passed a different list publickey,gssapi-with-mic,password
debug3: preferred gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup gssapi-with-mic
debug3: remaining preferred: publickey,keyboard-interactive,password
debug3: authmethod_is_enabled gssapi-with-mic
debug1: Next authentication method: gssapi-with-mic
debug3: Trying to reverse map address 192.168.1.75.
debug1: Unspecified GSS failure.  Minor code may provide more information
Unknown code krb5 195

debug1: Unspecified GSS failure.  Minor code may provide more information
Unknown code krb5 195

debug1: Unspecified GSS failure.  Minor code may provide more information
Unknown code krb5 195

debug2: we did not send a packet, disable method
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /home/saguna/.ssh/identity
debug3: no such identity: /home/saguna/.ssh/identity
debug1: Offering public key: /home/saguna/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Trying private key: /home/saguna/.ssh/id_dsa
debug3: no such identity: /home/saguna/.ssh/id_dsa
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
[email protected]'s password: 

    

Answer 1

O problema é que eu tinha o RSAAuthentication desabilitado em / etc / ssh / ssh_config

    

Answer 2

9/10 vezes é porque ~ / .ssh / authorized_keys não está no modo certo.

chmod 600 ~/.ssh/authorized_keys

    

Answer 3

Verifique em / etc / ssh / sshd_config para permitir a autenticação com uma chave. Você deve ter algo assim e garantir que as linhas não sejam comentadas:

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile  .ssh/authorized_keys

PS: não esqueça de reiniciar o sshd depois de modificar o arquivo (/etc/init.d/sshd restart)

    

Answer 4

Eu não sou um especialista aqui, mas também vi esse problema, aqui estão meus dois centavos além de todas as outras sugestões.

Às vezes, ssh-copy-id copia a chave errada para o servidor remoto (pode acontecer se você tiver várias chaves e / ou estiver usando nomes não padrão para arquivos de chaves) ou se seu agente de autenticação estiver configurado incorretamente.

Veja uma citação das páginas do manual :

If the -i option is given then the identity file (defaults to ~/.ssh/id_rsa.pub) is used, regardless of whether there are any keys in your ssh-agent. Otherwise, if this: ssh-add -L provides any output, it uses that in preference to the identity file.

Então, basicamente, você quer verificar isso:

• Seu agente de autenticação do sistema (geralmente ssh-agent) vê as chaves que você pretende usar (verifique ssh-add -L output)
  • Se você não encontrar a chave desejada, adicione-a usando ssh-add
• O ssh-copy-id copiou a mesma chave para a máquina remota (faça login no servidor remoto usando senha e verifique o conteúdo de ~/.ssh/authorized_keys )
  • Se você não vir a chave desejada no servidor remoto, poderá informar implicitamente ssh-copy-id qual chave copiar: ssh-copy-id -i ~/.ssh/some_public_key

Espero que ajude.

    

Answer 5

O problema mais comum é o de permissões inválidas no lado do servidor. Verifique se nenhum dos seus diretórios home, ~/.ssh e ~/.ssh/authorized_keys são graváveis por ninguém além de você (em particular, eles não devem ser graváveis em grupo).

Se esse não for o problema, execute ssh -vvv server e observe a visão do cliente sobre a conversa. Em particular, verifique se o cliente está tentando a chave com o servidor.

    

Answer 6

Descobri que, com o meu sistema, o problema era que o diretório do usuário (/ home / username) estava equipado com o conjunto de permissões incorretas. Era drwxr-x-w- e precisava ser drwxr-xr-x (com permissão de gravação apenas para o proprietário). A solução foi usar chmod:

sudo chmod 0755 /home/username

    

Answer 7

Além de todos os itens acima, sempre é possível verificar o arquivo de log sshd:

/var/log/auth.log

    

Answer 8

no meu caso / etc / ssh / sshd_config continha o seguinte parâmetro:

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile  .ssh/authorized_keys2

Mas o ssh-copy-id criou um arquivo com o nome authorized_keys, então eu tive que modificar a entrada para o novo nome. mais informações sobre deprecated authorized_keys2

    

Answer 9

Eu tentei as outras correções, mas descobri que precisava alterar o diretório inicial para não ser gravável por outras pessoas. O diretório inicial era 777. Eu mudei para 755 e funcionou.

    

Answer 10

Como complemento da resposta do Omer Dagan para o novo CentOS 7, use:

journalctl -f -u sshd

para ver os logs do sshd no servidor.