☰

Não é possível conectar via SSH e chave pública e o usuário B (o usuário A pode)

tag-icon • tag-icon ssh login
Não é possível conectar via SSH e chave pública e o usuário B (o usuário A pode)

RESOLVIDO.Foi a parte gravável do grupo no user_Bdiretório inicial que me enganou.

Estou ficando sem ideias sobre este. Cada dica seria muito apreciada.

Considere esta configuração:

  • Um servidor Srodando Ubuntu, users boldewyneuser_Auser_B
  • Dois laptops Aand B, cada um com um usuário local boldewyn(possui uma id_rsachave para fazer login S) e uma segunda chave id_rsa_A/ id_rsa_B. Todas as chaves são armazenadas em /home/boldewyn/.ssh. Ambos rodando Ubuntu.

  • user_Ae user_Bcom Ssenhas vazias, o login deve ser possível apenas via chave pública e SSH.

    +--------+            +-------------------+            +--------+
| laptop |            |       server      |            | laptop |
|   A    |            |         S         |            |   B    |
|        |            |                   |            |        |
+--------+    SSH     +-------------------+    SSH     +--------+
|id_rsa_A|------------|< user_A   user_B >|------------|id_rsa_B|
+--------+            +-------------------+            +--------+
|id_rsa  |------------|<    boldewyn     >|------------|id_rsa  |
+--------+            +-------------------+            +--------+

O que funciona:

  • Faça login em qualquer laptop como boldewyn(usando id_rsaeS:/home/boldewyn/.ssh/authorized_keys

  • Faça login no laptop Acomo usuário ( user_Ausando id_rsa_Ae S:/home/user_A/.ssh/authorized_keys:)ssh -i id_rsa_A user_A@S

Meu problema:No laptop, Bexatamente a mesma configuração falha para o user_B. Não consigo fazer login S, porque por algum motivo a chave não é aceita e vem o prompt de senha ( user_Bnão tem senha, não tem opção).

O que eu verifiquei:

  • No portátil B:

    • Verificou os direitos ~/.sshe todo o seu conteúdo
    • coloque public parte de id_rsa_Bin boldewyns .authorized_keyse ssh -i id_rsa_B boldewyn@S: funciona (a chave não está corrompida ou algo assim)
    • ssh -vvv: Bem, não é realmente útil: apenas me disse em um ponto que publickeyagora ele pula o método. Nenhuma razão dada.

  • No servidor S:

    • Arquivo user_Bs verificado três vezes.authorized_keys
    • Verificou os direitos /home/*/.sshe todos os seus conteúdos (especialmente comparados user_Ae user_B)
    • Verificado se $HOMEestá definido (via sudo -u user_B -i)
    • Verificado se todos os usuários estão em /etc/ssh/sshd_configs AllowUsers(e AllowGroups, a propósito)

Outras coisas:

A única diferença que consigo encontrar entre user_Ae user_Bé que criei o último adduser -M(não crie um diretório inicial; ele já existia antes). No entanto, verifiquei três vezes se isso /home/user_Be todas as crianças relevantes pertencem user_Ba seu grupo principal.

Responder1

Você verificou isso três vezes/home/user_B(assim como /home/user_B/.sshe /home/user_B/.ssh/authorized_keys) tinham as permissões adequadas:não gravável exceto para o usuário, ou seja, modo 755 ou mais restritivo?

Responder2

Acho que pode estar relacionado à maneira como você gerou essas chaves. Eu tentaria novamente. As chaves são geradas com o recurso ssh-keygen. Talvez quando um conjunto de chaves foi gerado, uma senha longa foi usada no processo de geração. Você pode tentar apenas pressionar a tecla Enter quando for solicitada uma senha. Copie a parte pub dessa chave para o Ubuntu. Certifique-se de excluir a entrada incorreta no arquivo .ssh/authorized_keys. Um segundo pensamento: se for cat o arquivo pub, certifique-se de usar >> (anexar) em vez de > (substituir_ ao copiar o arquivo pub para o arquivo autorizado_keys. (cat id_rsa.pub >> .ssh/authorized_keys).

Estou um pouco surpreso. Usei meus métodos no trabalho, usando Solaris e Cygwin, e em casa em minha LAN Linux composta por Centos, Slackware, Debian e Ubuntu. É possível que sua chave privada não corresponda à pública? Ao gerar suas chaves, você obtém um par, o púbico será copiado tradicionalmente para o arquivo .ssh/authorized keys no diretório inicial da máquina de destino. Se você gerar novamente as chaves, o novo arquivo .pub deverá ser copiado. A nova chave privada não irá emparelhar com a antiga pública. Percebo que você parece ter uma pasta .authorized_keys no diretório inicial. Eu nunca tentei isso. Acho que o posicionamento normal está na pasta /home/user_name/.ssh/authorized_keys. Nunca tive problemas ao usar qualquer versão do Solaris a partir da versão 6, Freebsd e várias iterações e versões do Linux. Boa sorte

Alan

informação relacionada