ssh-copy-id não funciona

19

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

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

O cliente ainda solicitou a senha. Do que eu senti falta?

Obrigado.

EDIT: verificado ssh_config e permissões conforme recomendado. Estas são as informações 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: 
jackhab
fonte
Eu também recebo isso :(
Matt Joiner

Respostas:

19

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

chmod 600 ~/.ssh/authorized_keys
JustinShoffstall
fonte
2
Para sua informação, criei um pequeno script em github.com/centic9/generate-and-send-ssh-key que executa as etapas necessárias de uma só vez e garante adicionalmente todas as permissões de arquivo / diretório que sempre me causavam dores de cabeça ...
centic
5
Se isso não funcionar para alguém, você também deve procurar a resposta de @ Gilles. Em particular, o diretório inicial e os~/.ssh diretórios não podem ser gravados por ninguém que não seja o usuário.
Ostrokach #
Sei que isso é antigo, mas agradeço um milhão ao @centic. Eu tinha certeza de que minhas permissões estavam corretas, mas nunca me preocupei em verificar os diretórios $ HOME e .ssh /.
jdferreira
Trabalhou para mim. Obrigado!
Ivan Kovtun
12

Faça check-in em / etc / ssh / sshd_config para permitir a autenticação com uma chave. Você deve ter algo assim e verifique se as linhas não são 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)

Patkos Csaba
fonte
Além da resposta de Patkos Csaba, verifique as permissões da pasta ~ / .ssh local e remota.
No meu caso, AuthorizedKeysFilefoi comentado e eu também tive que usar um caminho absoluto para authorized_keys.
28814 Andrew Andrew
Recebo 'Não foi possível abrir uma conexão com seu agente de autenticação'. ao tentar ssh-add
Manticore 4/15
esta deve ser a resposta escolhida
Francisco Tapia
Talvez você não entenda os comentários. As linhas comentadas mostram os valores padrão. Você não precisa descomentá-los se quiser o valor padrão. Você só precisa remover o comentário da propriedade se desejar substituir o valor padrão.
Clearlight 06/0318
5

Eu descobri que no meu sistema o problema era que o diretório do usuário (/ home / nome de usuário) 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 o chmod:

sudo chmod 0755 /home/username
Charlie
fonte
11
Yah! Trabalhou para mim. O ssh estava me dando uma solicitação de senha porque eu estraguei as persuasões.
Clearlight 06/0318
4

Não sou especialista aqui, mas também deparei com essa questão. Aqui estão meus dois centavos , além de todas as outras sugestões.

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

Aqui está uma citação das páginas de manual :

Se a opção -i for fornecida, o arquivo de identidade (o padrão é ~ / .ssh / id_rsa.pub) será usado, independentemente de haver chaves no seu ssh-agent. Caso contrário, se este: ssh-add -L fornecer qualquer saída, ele será usado preferencialmente ao arquivo de identidade.

Então, basicamente, você deseja verificar se:

  • O agente de autenticação do sistema (geralmente ssh-agent) vê as chaves que você pretende usar (verifique a ssh-add -Lsaída)
    • Se você não vir a chave desejada, adicione-a usando ssh-add
  • A ssh-copy-idmesma chave foi copiada para a máquina remota (faça o login no servidor remoto usando a senha e verifique o conteúdo de ~/.ssh/authorized_keys)
    • Se você não vir a chave desejada no servidor remoto, poderá dizer implicitamente ssh-copy-idqual chave copiar:ssh-copy-id -i ~/.ssh/some_public_key

Espero que ajude.

Dmitry Pashkevich
fonte
11
Você acertou em cheio! Escavando o meu ssh-copy-id problema é :, DEFAULT_PUB_ID_FILE=$(ls -t ${HOME}/.ssh/id*.pub 2>/dev/null | grep -v -- '-cert.pub$' | head -n 1)que será o padrão para a primeira chave alfabética - no meu caso, eu tinha um id_boot2docker.pub(que é aparentemente o nome padrão para o material boot2docker ssh). Parece que existem várias implementações diferentes de ssh-copy-id; veio o meu brew install ssh-copy-id, que por sua vez é retirado do openssh-portable. Minha página do homem menciona explicitamente esse comportamento ...
Christian Ulbrich
3

O problema mais comum são permissões inválidas no lado do servidor. Verifique se nenhum dos seus diretórios pessoais ~/.sshe ~/.ssh/authorized_keysé gravável por qualquer pessoa, exceto você (em particular, eles não devem ser graváveis ​​em grupo).

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

Gilles 'SO- parar de ser mau'
fonte
Obrigado!!! Eu não entendo por que, mas a sua pasta pessoal , ~/.sshe ~/.ssh/authorized_keysnão pode ser gravável por qualquer pessoa, mas você.
Ostrokach #
2

Além de todas as opções acima, sempre é possível verificar o arquivo de log sshd:

/var/log/auth.log
Omer Dagan
fonte
1

Tentei as outras correções, mas achei que precisava alterar o diretório inicial para não poder ser gravado por outras pessoas. O diretório inicial era 777. Mudei para 755 e funcionou.

dulcana
fonte
11
welcome @dulcana, ele tenta definir um login ssh sem senha, como alterar as permissões para 755 pode ajudar a resolver o problema?
Francisco Tapia
@FranciscoTapia, porque o sshd garante que outros usuários não possam ter criado maliciosamente o arquivo allowed_keys, recusando o login por ssh key, onde um grupo ou outro pode gravar o arquivo ou qualquer um de seus pais. Outras respostas também mencionaram isso.
Ángel
0

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 author_keys, então tive que modificar a entrada para o novo nome. mais informações sobre chaves_ autorizadas descontinuadas2

Laplasz
fonte
0

Como complemento à resposta de Omer Dagan para o CentOS 7 mais recente, use:

journalctl -f -u sshd

para olhar os logs sshd no servidor.

david.perez
fonte
-1

O problema foi que o RSAAuthentication foi desativado em / etc / ssh / ssh_config

jackhab
fonte