autorizado_keys tem minha chave, mas ela ainda foi recusada

autorizado_keys tem minha chave, mas ela ainda foi recusada

Estou conectando da máquina M1 à máquina M2 usando ssh (para o mesmo usuário na outra máquina). Devo também mencionar que o usuário compartilha a mesma chave nas duas máquinas. Com autenticação por senha, tudo funciona bem; o mesmo não acontece com a autenticação de chave pública; Garanti ~/.ssh/authorized_keysque o M2 tenha a chave RSA autorizada, mas ainda assim - o ssh volta para a autenticação por senha. Eu recebo o seguinte com ssh -vvv:

debug2: key: /home/joeuser/.ssh/id_rsa (0x7f42679e8200),
debug2: key: /home/joeuser/.ssh/id_dsa ((nil)),
debug2: key: /home/joeuser/.ssh/id_ecdsa ((nil)),
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug3: start over, passed a different list publickey,password,keyboard-interactive
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/joeuser/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Trying private key: /home/joeuser/.ssh/id_dsa
debug3: no such identity: /home/joeuser/.ssh/id_dsa: No such file or directory
debug1: Trying private key: /home/joeuser/.ssh/id_ecdsa
debug3: no such identity: /home/joeuser/.ssh/id_ecdsa: No such file or directory
debug2: we did not send a packet, disable method

Devo mencionar que eusoucapaz de se conectar usando autenticação de chave pública de outras máquinas (não com a mesma chave).

Quais são os possíveis motivos para a falha da autenticação baseada em chave neste caso?

Nota: As máquinas são ambas SLES (SuSE Linux Enterprise Server) 11.

Responder1

Você estava fazendo a coisa certa usando ssh -vvvo cliente, emparelhe-o com um sshd em modo de depuração, assim:

uma segunda instância de servidor: # /usr/sbin/sshd -p 1234 -dddd

um cliente dedicado para conectar: $ ssh -i .ssh/id_rsa-admuser admuser@server -p 1234 -vvvv

No meu caso, descobriu-se que as informações cruciais foram impressas apenas no cliente. O servidor passou

debug2: user_key_allowed: check options...
debug2: user_key_allowed: advance ...
debug2: key not found

enquanto o cliente veio com isso:

debug1: Next authentication method: publickey
debug1: Offering public key: .ssh/id_rsa-admuser RSA SHA256:<censored> explicit agent
debug1: send_pubkey_test: no mutual signature algorithm

Então, o que estava acontecendo aqui?

O servidor era tão antigo que não era possível negociar um algoritmo auxiliar; a chave também eradatado, mas geralmente bem.

Qual seria a abordagem básica agora?

  1. inicie o servidor dedicado em uma porta diferente
  2. conectar-se do cliente em nova sessão
  3. compare a troca de chaves em ambos os lados, passo a passo
  4. validar descobertas usando um segundo par de chaves recém-gerado

Neste exemplo específico houve uma explicação clara de que se tratava de um método antigo e inseguro que havia sido obsoleto, ou seja, descrito aqui. https://confluence.atlassian.com/bitbucketserverkb/ssh-rsa-key-rejected-with-message-no-mutual-signature-algorithm-1026057701.html

Para poder atualizar aquela caixa antiga, eu poderia conectar adicionando -o PubkeyAcceptedKeyTypes=+ssh-rsaà linha de comando ssh no cliente.

Responder2

Verifique o básico:

  1. id_rsa e id_rsa.pub existem em M1 e M2
  2. id_rsa tem permissão 600 (ou seja, apenas o proprietário pode ler e escrever) em M1 e M2
  3. arquivo autorizado_keys tem chave colada como uma única linha (sem quebra de linha)
  4. A permissão deauthorized_keys é 600
  5. Normalmente, a permissão na minha pasta .ssh é 600 (padrão)
  6. Verifique a permissão de cada pasta/home até .ssh
  7. Eu sei que você deseja usar RSA, mas experimente a chave DSA e veja se funciona. Se isso acontecer, teremos zerado a configuração SSH e RSA.

Responder3

O erro que você recebe é

/home/joeuser/.ssh/id_dsa: No such file or directory

Certifique-se de que este arquivo exista, contenha a chave privada que corresponde à chave pública que você adicionou, pertença joeusere tenha 600permissões de usuário:

sudo chown joeuser /home/joeuser/.ssh/id_dsa
sudo chmod 600 /home/joeuser/.ssh/id_dsa

Você também deve tentar definir explicitamente a chave privada assim:

ssh -i ~/.ssh/id_rsa [email protected]

Se você não tem certeza se esta é a chave correta, recomendo criar um novo par de chaves RSA

ssh-keygen -b 4096

e adicione o conteúdo da chave pública ~/.ssh/id_rsa.pubao arquivoauthorized_keys do servidor remoto. Certifique-se de não substituir uma chave privada existente que ainda precisa para fazer login em outros servidores!

informação relacionada