Não é possível conectar via SSH e publickey e usuário B (usuário A pode)

RESOLVIDO Foi o grupo gravável em user_B s home diretório, que me enganou.

Estou ficando sem ideias sobre isso. Cada sugestão seria muito apreciada.

Considere esta configuração:

• Um servidor S executando Ubuntu, usuários boldewyn, user_A e user_B
• Dois laptops A e B, cada um com um usuário local boldewyn (tem um id_rsa chave para entrar S ) e uma segunda chave id_rsa_A / id_rsa_B. Todas as chaves são armazenadas em /home/boldewyn/.ssh. Ambos rodando o Ubuntu.

• user_A e user_B em S tem senhas vazias, o login deve ser possível somente via publickey 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 o login de qualquer laptop como boldewyn (usando id_rsa e S:/home/boldewyn/.ssh/authorized_keys

• Faça login no laptop A como usuário user_A (usando id_rsa_A e S:/home/user_A/.ssh/authorized_keys: ssh -i id_rsa_A user_A@S )

Meu problema: No laptop B exatamente a mesma configuração falha para user_B. Não consigo fazer login Sporque, por algum motivo, a chave não é aceita eo prompt de senha é enviado ( user_B não tem senha, isso não é uma opção).

O que eu verifiquei:

• No laptop B:

  • Verificou os direitos de ~/.ssh e todo o seu conteúdo
  • colocar parte pública de id_rsa_B em boldewyn s .authorized_keys e ssh -i id_rsa_B boldewyn@S: funciona (a chave não está corrompida ou assim)
  • ssh -vvv: Bem, não é realmente útil: Apenas me diz em um ponto, que ele pula publickey método agora. Nenhuma razão dada.

• No servidor S:

  • Tridimensional user_B s .authorized_keys Arquivo
  • Verificou os direitos de /home/*/.ssh e todo o seu conteúdo (especialmente comparado user_A e user_B )
  • Verificado que $HOME está definido (via sudo -u user_B -i )
  • Verificado, que todos os usuários estão em /etc/ssh/sshd_config s AllowUsers (e AllowGroups, a propósito)

Outras coisas:

A única diferença que eu posso fazer entre user_A e user_B é que eu criei o último com adduser -M (não crie um diretório inicial; ele já existia antes). No entanto, eu verifiquei /home/user_B e todas as crianças relevantes são de propriedade de user_B e seu grupo primário.

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

Acho que isso 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 foi usada no processo de geração. Você pode tentar apenas pressionar a tecla Enter quando for solicitada uma frase secreta. Copie a parte do pub dessa chave para o Ubuntu. Certifique-se de excluir a entrada incorreta no arquivo .ssh / authorized_keys. Um segundo pensamento: se catar o arquivo de publicação, certifique-se de usar uma & gt; & gt; (acrescentar) em vez de & gt; (substitua_ quando você copiar o arquivo pub para o arquivo authorized_keys. (cat id_rsa.pub & gt; & gt; .ssh / authorized_keys).

Estou um pouco surpresa. Eu usei meus métodos no trabalho, usando o Solaris e o Cygwin, e em casa no meu Linux Lan, que era composto por Centos, Slackware, Debian e Ubuntu. É possível que sua chave privada não corresponda à pública? Quando você gera suas chaves, você obtém um par, o púbico será copiado tradicionalmente para o arquivo .ssh / authorized keys sob o 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 será emparelhada com a antiga pública. Percebo que você parece ter uma pasta .authorized_keys no diretório inicial. Eu nunca tentei isso. Eu acho que o posicionamento normal está na pasta /home/user_name/.ssh/authorized_keys. Eu nunca tive problemas ao usar qualquer versão do Solaris de aproximadamente 6 em diante, Freebsd e várias iterações e sabores do Linux. Boa sorte

Alan