Você fez uma verificação tripla de que /home/user_B (bem 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?
RESOLVIDO. Era o bit gravável do grupo no diretório inicial user_B s, que me enganou.
Estou ficando sem ideias sobre isso. Cada sugestão seria muito apreciada.
Considere esta configuração:
S executando o Ubuntu, usuários boldewyn , user_A e user_B
A e B , cada um com um usuário local boldewyn (tem uma chave id_rsa 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 o Ubuntu. user_A e user_B on S têm senhas vazias, o login deve ser possível somente por meio de 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 login em 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 logar em S , porque por alguma razão a chave não é aceita e o prompt da senha vem ( user_B não tem senha, isso não é uma opção).
O que eu verifiquei:
No laptop B :
~/.ssh e todo o seu conteúdo id_rsa_B em boldewyn s .authorized_keys e ssh -i id_rsa_B boldewyn@S : works (a chave não está corrompida) ssh -vvv : Bem, não é realmente útil: Apenas me diz em um ponto que ele ignora o método publickey agora. Nenhuma razão dada. No servidor S :
user_B s .authorized_keys file /home/*/.ssh e todo o conteúdo deles (especialmente em comparação com user_A e user_B ) $HOME está definido (via sudo -u user_B -i ) /etc/ssh/sshd_config s AllowUsers (e AllowGroups , a propósito) Outras coisas:
A única diferença que posso fazer entre user_A e user_B é que criei o último com adduser -M (não crie um diretório inicial; ele já existia antes). No entanto, verifiquei três vezes que /home/user_B e todos os filhos relevantes são de propriedade de user_B e seu grupo principal.
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 você usar o arquivo de publicação, certifique-se de usar uma > > (acrescentar) em vez de > (substitua_ quando você copiar o arquivo pub para o arquivo authorized_keys. (cat id_rsa.pub > > .ssh / authorized_keys).
Estou um pouco surpreso. Eu usei meus métodos no trabalho, usando o Solaris e o Cygwin, e em casa no meu Linux Lan, 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 home 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