Por que o login automático por meio do ssh com o author

12

Eu criei um dsa-keypair privado / público. Coloquei a chave pública no servidor

~/.ssh/authorized_keys

Tudo está configurado como meu outro servidor, mas parece que o servidor está apenas ignorando meus esforços.

security ssh login

— Magnar
fonte

Verifique /etc/ssh/ssh_confige /etc/ssh/sshd_configverifique se nada do que você deseja está desativado.

— 30511 Kristopher Johnson

Você também deve verificar o sshd_config.

— Vagnerr 30/04/09

Obrigado. Atualizei a resposta (que originalmente mencionava apenas ssh_config).

— 30511 Kristopher Johnson

Todas as discussões acima são perfeitas se você estiver usando um estilo openssh do ssh. Se o seu sistema estiver usando o ssh2, ele possui uma maneira totalmente estranha de gerenciar chaves. Este artigo discute os comos e o que é. burnz.wordpress.com/2007/12/14/…

— chris

1

Normalmente, a verificação /var/log/auth.logem sistemas Debian ou /var/log/secureem uns RedHat deve dar-lhe um conselho clara do que está misconfidured (geralmente problemas de permissões)

— Giovanni Toraldo

15

Embora seu problema já possa ter sido resolvido por outras respostas, eu me impedi de máquinas suficientes de não validar as alterações sshd_config antes de terminar a sessão, então criei o processo abaixo que pode ser útil para depuração futura das alterações de configuração do sshd:

NÃO DESCONECTE uma conexão ssh ativa até que APÓS o teste tenha verificado que o comportamento é o esperado.

uma. verifique o que você acha que o sshd deveria estar fazendo

b. verifique se a configuração é válida usando "-t"

c. iniciar uma versão detalhada 'teste' do servidor que você pode monitorar ao vivo

d. iniciar uma conexão de cliente 'teste' detalhada, você pode viver monitor

uma. verifique o que você acha que o sshd deveria estar fazendo

Revise o arquivo de configuração sshd sem todos os comentários com algo como o abaixo (assumindo que sshd_config é o arquivo correto e em / etc / ssh)

$ grep -v "^ #" / etc / ssh / sshd_config | grep -v "^ $"

Isso apenas esclarece as coisas, para que possamos verificar o que achamos que estamos mudando (não necessariamente se está correto ou não).

b. verifique se a configuração é válida usando "-t"

Na página de manual do sshd que estou usando,

-t modo de teste. Verifique apenas a validade do arquivo de configuração e a integridade das chaves. Isso é útil para atualizar o sshd de forma confiável, pois as opções de configuração podem mudar.

Outras mudanças podem ter circunstâncias mais sutis. Por exemplo, não desative a autenticação de senha até ter certeza de que a autenticação de chave pública está funcionando corretamente.

c. iniciar uma versão detalhada 'teste' do servidor que você pode monitorar ao vivo

$ sudo / usr / sbin / sshd -ddd -p 9999

Isso mantém sua sessão de trabalho existente ativa, mas fornece outra instância do sshd para verificar suas novas alterações na configuração. Agora, o SSHD está sendo executado em primeiro plano em uma porta definida pelo usuário (9999 no nosso exemplo.) E fornecendo muitas informações de depuração ruidosas que você pode rastrear em / var / log / authlog (ou possivelmente /var/log/auth.log dependendo no seu sistema operacional.)

d. iniciar uma conexão de cliente 'teste' detalhada, você pode viver monitor

Execute a conexão do cliente ssh no modo detalhado para exibir na tela mais informações que podem levar você a depurar melhor seu erro.

$ ssh -vvv -p 9999 nome do servidor

Agora você deve ter informações suficientes nos arquivos de log do servidor ou na tela de conexão do cliente para isolar seu problema.

A solução geralmente se resume a permissões de arquivo (como mostrado por Magnar e setatakahashi)

Boa sorte

— samt
fonte

Eu acho que você também deve verificar o arquivo ssh_config no lado do cliente para garantir que está fazendo o que você espera. Use algo como o abaixo para destacar os comentários:> grep -v "^ #" / etc / ssh / ssh_config | grep -v "^ $"

— 25/05/2009

Bem, a configuração do cliente ssh pode ser corrigida a qualquer momento, é o servidor do qual você fica bloqueado se a configurou incorretamente.

— Soviero

33

O servidor ignorará o seu arquivo allowed_keys se as propriedades do proprietário estiverem incorretas. Alterar para isso corrige:

chmod 0700 ~/.ssh
chmod 0600 ~/.ssh/authorized_keys

— Magnar
fonte

6

ssh -vvv -l username server.domain irá dizer-lhe se o seu envio de uma chave válida

— Dave Cheney

Às vezes, vejo o sshd reclamar de permissões ruins no diretório inicial - então adiciono "chmod o-rwx ~" (ou pelo menos "chmod ow ~") à lista, como setatakahashi fez. Isso geralmente se torna óbvio quando o arquivo de log é monitorado - as mensagens de erro que eu vi lá sempre apontam na direção correta.

— Olaf

Essa resposta parece ser a mais provável, mas o comentário de Dave Cheney é a única maneira de ver o que realmente está acontecendo. Verifique também os logs do servidor.

— Dwc 24/05/09

Este foi o meu problema. Eu bati minha cabeça nisso por horas. Muito obrigado!

— Sam Soffes 5/11

1

Isso fez o truque, mas minhas permissões anteriores foram 0775e 0644respectivamente. Por que a redução das permissões ajudou? Esta é uma precaução de segurança configurada em algum lugar?

— Dean

11

$ chmod 700 ~

$ chmod 700 ~ / .ssh

$ chmod 600 ~ / .ssh / chaves_autorizadas

Verifique esses atributos em / etc / ssh / sshd_config

$ sudo grep PubkeyAuthentication / etc / ssh / sshd_config

$ sudo grep Protocolo / etc / ssh / sshd_config

— setatakahashi
fonte

2

Excelente ponto sobre ~, você deve se certificar de que ninguém além de você mesmo pode escrever para seu diretório home, caso contrário, eles poderiam mudar o nome do ~ / .ssh diretório

— Dave Cheney

esse último chmod deve ser: $ chmod 600 ~/.ssh/authorized_keysnot$ chmod 600 ~/.sHh/authorized_keys

— SooDesuNe

3

o que deve os valores de atributo ser ?

— Michael

0

Outra armadilha importante ..

Se o seu diretório pessoal estiver criptografado, o sshd não terá acesso a ~ / .ssh / allowed_keys.

Veja esta resposta

— A priori
fonte

Por que o login automático por meio do ssh com o author_keys não funciona?