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_keys
que 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 -vvv
o 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?
- inicie o servidor dedicado em uma porta diferente
- conectar-se do cliente em nova sessão
- compare a troca de chaves em ambos os lados, passo a passo
- 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:
- id_rsa e id_rsa.pub existem em M1 e M2
- id_rsa tem permissão 600 (ou seja, apenas o proprietário pode ler e escrever) em M1 e M2
- arquivo autorizado_keys tem chave colada como uma única linha (sem quebra de linha)
- A permissão deauthorized_keys é 600
- Normalmente, a permissão na minha pasta .ssh é 600 (padrão)
- Verifique a permissão de cada pasta/home até .ssh
- 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 joeuser
e tenha 600
permissõ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.pub
ao arquivoauthorized_keys do servidor remoto. Certifique-se de não substituir uma chave privada existente que ainda precisa para fazer login em outros servidores!