Quais são as armadilhas comuns que impediriam o acesso SSH da Chave Autorizada e como eu as localizo e corrijo para elas?

Question

EDITAR: Esta questão foi reformulada para torná-la mais útil para a comunidade e menos específica para mim.

As perguntas parecem surgir com certa frequência em relação ao ssh e aos problemas com o acesso por chaves autorizadas, mas muito poucos parecem ter uma resposta clara em qualquer lugar;

Servidor continua pedindo senha depois que eu copiei minha chave pública SSH para authorized_keys

ssh não aceita chave pública

como eu uso o ssh com chave acesso em 11.10

ssh sem senha não funciona

Então, na opinião das comunidades, qual é o método experimentado e testado para chegar ao fundo de tais problemas?

    

Answer 1

Analisando o problema

Existem dois lugares em que uma conexão ssh pode dar errado, no servidor ou no cliente. Queremos descartá-los um de cada vez.

No servidor

Para aumentar o registro no servidor, defina a seguinte linha em seu arquivo / etc / ssh / sshd_config;

  

DEBUG LogLevel

^{Há também um DEBUG2 e DEBUG3 para enviar ainda mais informações aos logs.}

Para monitorar os logs, use o comando tail -f /var/log/auth.log

No cliente

Você pode adicionar verbosidade à sua conexão do cliente com uma opção -v.

  

ssh -v [email protected]

^{Existe também um -vv e -vvv para aumentar a verbosidade da saída}

Detectando o erro

Defina seu monitoramento de log no servidor com o comando acima e tente conectar-se a ele do cliente usando um nível de detalhamento também acima. Agora, verifique cuidadosamente as saídas de cada uma delas e procure por não foi possível , Permissão negada , sem essa identidade: ou < strong> Identificador incorreto RSA1 's etc. Estes são provavelmente o problema se você estiver em uma posição similar a mim.

Armadilhas Comuns

Permissões - Lado do cliente

Os certificados e known_hosts (geralmente encontrados em ~ .ssh) precisam ser lidos pelo usuário. No instante mais simples, id_rsa, id_rsa.pub e knwon_hosts devem ser de propriedade de e no seu grupo de usuários e devem ser legíveis pelo usuário, abaixo está a configuração 'padrão'.

  

-rw ------- nome de usuário username id_rsa

     

-rw-r - r-- nome de usuário username id_rsa.pub

     

-rw-r - r-- nome de usuário username known_hosts

Permissões - Lado do servidor

Mais uma vez, os certificados e desta vez os arquivos authorized_keys devem ser legíveis pelo usuário que está logado. Padrões como mostrado abaixo:

  

-rw ------- username username authorized_keys

     

-rw-r - r-- nome de usuário username id_rsa

Unidades / diretórios criptografados

O SSH no servidor precisa ser capaz de ver / ler o arquivo authorized_keys e os certificados do servidor associado; portanto, se estiverem em um dispositivo criptografado, uma sessão deverá estar ativa para que o dispositivo seja legível pelo daemon. Isso geralmente é visto quando você pode fazer o login por senha e enquanto essa sessão estiver ativa, então você pode acessar via chaves autorizadas e sem senha.