%20e%20como%20ela%20difere%20do%20par%20de%20chaves%20p%C3%BAblica-privada%3F.png)
A situação é que já criei um VPS anteriormente. Estava tudo configurado, autenticação de chave pública-privada, login root desativado, login por senha desativado. Tudo foi configurado.
Então este servidor é destruído e um novo servidor é desmembrado.
Estou usando ssh -v root@new_server_ip_numberpara fazer login nesta instância do Linux recém-instalada e é isso que recebo:
PS C:\Users\roeslermichal> ssh -v [email protected]
OpenSSH_for_Windows_8.6p1, LibreSSL 3.4.3
debug1: Reading configuration data C:\\Users\\roeslermichal/.ssh/config
debug1: Authenticator provider $SSH_SK_PROVIDER did not resolve; disabling
debug1: Connecting to 10.32.81.216 [10.32.81.216] port 22.
debug1: Connection established.
debug1: identity file C:\\Users\\roeslermichal/.ssh/id_rsa type -1
debug1: identity file C:\\Users\\roeslermichal/.ssh/id_rsa-cert type -1
debug1: identity file C:\\Users\\roeslermichal/.ssh/id_dsa type -1
debug1: identity file C:\\Users\\roeslermichal/.ssh/id_dsa-cert type -1
debug1: identity file C:\\Users\\roeslermichal/.ssh/id_ecdsa type -1
debug1: identity file C:\\Users\\roeslermichal/.ssh/id_ecdsa-cert type -1
debug1: identity file C:\\Users\\roeslermichal/.ssh/id_ecdsa_sk type -1
debug1: identity file C:\\Users\\roeslermichal/.ssh/id_ecdsa_sk-cert type -1
debug1: identity file C:\\Users\\roeslermichal/.ssh/id_ed25519 type -1
debug1: identity file C:\\Users\\roeslermichal/.ssh/id_ed25519-cert type -1
debug1: identity file C:\\Users\\roeslermichal/.ssh/id_ed25519_sk type -1
debug1: identity file C:\\Users\\roeslermichal/.ssh/id_ed25519_sk-cert type -1
debug1: identity file C:\\Users\\roeslermichal/.ssh/id_xmss type -1
debug1: identity file C:\\Users\\roeslermichal/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_for_Windows_8.6
debug1: Remote protocol version 2.0, remote software version OpenSSH_8.0
debug1: compat_banner: match: OpenSSH_8.0 pat OpenSSH* compat 0x04000000
debug1: Authenticating to 10.32.81.216:22 as 'root'
debug1: load_hostkeys: fopen C:\\Users\\roeslermichal/.ssh/known_hosts2: No such file or directory
debug1: load_hostkeys: fopen __PROGRAMDATA__\\ssh/ssh_known_hosts: No such file or directory
debug1: load_hostkeys: fopen __PROGRAMDATA__\\ssh/ssh_known_hosts2: No such file or directory
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ssh-ed25519
debug1: kex: server->client cipher: [email protected] MAC: <implicit> compression: none
debug1: kex: client->server cipher: [email protected] MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: SSH2_MSG_KEX_ECDH_REPLY received
debug1: Server host key: ssh-ed25519 SHA256:5OrjMYiYdmoRTDgjsmBfOXun/4FpiClOU6L21gBDPSk
debug1: load_hostkeys: fopen C:\\Users\\roeslermichal/.ssh/known_hosts2: No such file or directory
debug1: load_hostkeys: fopen __PROGRAMDATA__\\ssh/ssh_known_hosts: No such file or directory
debug1: load_hostkeys: fopen __PROGRAMDATA__\\ssh/ssh_known_hosts2: No such file or directory
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ED25519 key sent by the remote host is
SHA256:5OrjMYiYdmoRTDgjsmBfOXun/4FpiClOU6L21gBDPSk.
Please contact your system administrator.
Add correct host key in C:\\Users\\roeslermichal/.ssh/known_hosts to get rid of this message.
Offending RSA key in C:\\Users\\roeslermichal/.ssh/known_hosts:15
Host key for 10.32.81.216 has changed and you have requested strict checking.
Host key verification failed.
O que é essa SHA256:5OrjMYiYdmoRTDgjsmBfOXun/4FpiClOU6L21gBDPSk.linha? O que isso significa?
Porque claramente este SHA256:5OrjMYiYdmoRTDgjsmBfOXun/4FpiClOU6L21gBDPSk.número/id não é o mesmo número que identifica o servidor Linux no meu known_hostsarquivo do Windows.
Estou usando um laptop Windows e PowerShell para fazer login neste servidor.
Há um C:\Users\roeslermichal\.ssh\known_hostsarquivo nesta máquina Windows e eu esperava que alguns IDs não correspondessem, porque o servidor antigo foi destruído e o novo foi criado. Já apaguei a 10.32.81.216 ssh-rsachave e substituí-a por esta 10.32.81.216 ssh-rsachave do servidor Linux recém-instalado.
Mas o cliente ssh não me deixa entrar.
É assim que meu :\Users\roeslermichal\.ssh\known_hostsarquivo atual se parece:
10.32.81.216 ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIGh8fEmrCov7TLbiKgGasUV3fxbrKmh4Ai/RWixt41Fl
10.32.81.216 ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQCr43mfkweJAaHQ4kw88b0y5OShnQl91jR1eoUIcnaMRvBEi3X7McVuA+cB+MWk4Rj9EX2hnq6tyB+26weQX0GXWf95CL/yqX5p39b+j8c43CR9/3gHbU5aV+exGBbj2rEL4JgmQD58fHHEsL1r6EMcpTUgY8JqfG0F52XUJrF7KdpxlW4vtgOaHdqooBMHuMi+bR7LRq/moAHLv3svB5PPhIfSbM5CW/Eke4H4qiAwKCVUjyXxKCoKkYVDyfQur+nBMxJssUHy03385hxV0gKo8WGQKlSNvI3B1vP85ij5zCYViYUfs05lXPkpsUqosGqHDOJhPnVRM4OacMQVkj2e0MKHs/cXA1GneBiY99tPMaEL2qZ0UJoaYcnG0krc0owKE6Ufx+84VVqLG7hJHPnNRI3UrFjG/C7lAzAogz5eDiYoQvkko7mLuwRob27fIB39oH2cbH4a4DCcIDekS0WwCPeA+uwaHrmhKJluqP8r7qvDluWax3cVzDGojD7I6cU=
10.32.81.216 ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBCMktfR/tBD8GYWRWpo8DsoIPPxos+Rt/C1Is04S0Dglm6UbQqQQUW9m9GfDWHZn3j37ZWPGeUwTcWEojKi70yk=
10.32.81.218 ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIFBuju3Gav0s6Uj8XFQToa/qU7gxsxvKqtUCctWaC4FC
10.32.81.218 ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQC6OCnBNeCfiLcYo7FAmopNBxWS5No+Locw+dxujELxhXn/zAEEnsMv+fZYP8JT8Jj+bYFX1jVAxBubqaz7swK3GCYkkL4C/dI2p7MV0E0ogznbZEZS0GHU3wA69R7s4F56oR3ZeCIas+gfe3mckB4i9UtZMy2IsGSVl974wletCXfdXxhkyRzHlgovoCnAYu9qOS/X2X2yuUNKKfL3VGQNkAih/Hjqh7Iwi36sLS8+WB/sYOk5cxJfycWewTEl1Wt5fB5bbc7Fu0Wmjn2IpMHspoR6YEw2lK/GuFIFjcVoHJ8+7JAuY9BnUdyuAbHLZ8vgrymcGw/ZP8GIhgRq1nOseAQrOzZMFtcGCS953a+L5gP9shX2ZwF/MS7h8+EYPxMNFZP6DbU++c4ZmOlb0lPkUJDhTnSbOoDZA+bfDl5jBlKtfF2V7n+V9Dwuwwbsp/qJyULIeMAdCrpjPhmKhnQASloZsEN5LLjh2gVN+YM7jACHe6ZyFD4/gpEE6N6MUG8=
10.32.81.218 ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBBonnCuOeQpc7CSRzbps8sLnPYMphNrfqs9h7Hz5I+Ml8QxPBUnlNw749EzqC29KFtyB8XE2SnbOK/CuUnghj5E=
Mas eu realmente não sei quais são essas chaves de host, porque não criei nenhuma chave neste novo servidor Linux. A abordagem de login como root foi a primeira ação que fiz em relação a este servidor Linux recém-criado. E já tem alguns host_keysnesse servidor.??? E essas não são chaves ssh público-privadas, porque ainda não as criei, então quais são essas chaves que foram geradas e identificam meu novo servidor Linux no known_hostsarquivo do Windows.
Eu lieste tópicocuidadosamente algumas vezes, mas não entendo muito bem as respostas dadas e por que elas funcionam. Ainda mais, não entendo por que não consigo fazer login em meu servidor Linux recém-criado, embora tenha substituído a antiga chave de host rsa do servidor por uma nova chave de host rsa do servidor.
PS C:\Users\roeslermichal> ssh-keyscan -t rsa 10.32.81.216
# 10.32.81.216:22 SSH-2.0-OpenSSH_8.0
10.32.81.216 ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQCr43mfkweJAaHQ4kw88b0y5OShnQl91jR1eoUIcnaMRvBEi3X7McVuA+cB+MWk4Rj9EX2hnq6tyB+26weQX0GXWf95CL/yqX5p39b+j8c43CR9/3gHbU5aV+exGBbj2rEL4JgmQD58fHHEsL1r6EMcpTUgY8JqfG0F52XUJrF7KdpxlW4vtgOaHdqooBMHuMi+bR7LRq/moAHLv3svB5PPhIfSbM5CW/Eke4H4qiAwKCVUjyXxKCoKkYVDyfQur+nBMxJssUHy03385hxV0gKo8WGQKlSNvI3B1vP85ij5zCYViYUfs05lXPkpsUqosGqHDOJhPnVRM4OacMQVkj2e0MKHs/cXA1GneBiY99tPMaEL2qZ0UJoaYcnG0krc0owKE6Ufx+84VVqLG7hJHPnNRI3UrFjG/C7lAzAogz5eDiYoQvkko7mLuwRob27fIB39oH2cbH4a4DCcIDekS0WwCPeA+uwaHrmhKJluqP8r7qvDluWax3cVzDGojD7I6cU=
Embora eu não tenha substituído a tecla 10.32.81.216 ssh-ed25519nem 10.32.81.216 ecdsa-sha2-nistp256. Pode ser esse o motivo pelo qual não consigo fazer login?
Responder1
Existe uma autenticação mútua no SSH.
Primeiro, oclienteautentica que o servidor é realmente aquele ao qual ele deseja se conectar. Para isso, ele lembra a parte pública do par de chaves do host no ~/.ssh/known_hostsarquivo. Ele aprende isso durante a primeira conexão (esta é exatamente a parte em que pede para você digitar "sim") ou pode aprender com o DNS se contiver o registro SSHFP do host e a zona estiver protegida por DNSSEC. Se o cliente descobrir que o servidor está apresentando a chave errada, ele normalmente se recusará a se conectar, alegando um ataque MitM em andamento.
É para isso que serve o par de chaves do host SSH. Grosso modo, é a versão SSH da infraestrutura PKI, embora não seja baseada em CA (ou usa DNSSEC para implementar uma cadeia de confiança semelhante a CA); é como um par de certificado/chave HTTPS (com a finalidade de "autenticação de servidor web") e tem a mesma finalidade. Istoéo par de chaves assimétricas ("pública-privada") que pertence a um servidor.
Em segundo lugar, oservidorautentica que o cliente é realmente quem afirma ser. Para isso, pode usar o par nome de usuário/senha ou qualquer autenticação complexa baseada em chat, ou o par de chaves assimétricas armazenado no servidor em users ~/.ssh/authorized_keys. Desta vez, o par de chaves pertence a um usuário. Novamente, a PKI tradicional baseada em CA possui certificados de cliente "analógicos" (com a finalidade de "autenticação de cliente web").
Bem, você vê esta linha em sua saída, Someone could be eavesdropping on you right now (man-in-the-middle attack)!? É assim que ele relata o ataque MitM que foi projetado para prevenir. Provavelmente é excessivamente cauteloso, mas esta é a sua segurança.
Se vocês sãocerteza absolutanão há ataque e a nova impressão digital é a correta, basta remover a linha incorreta do arquivoknown_hosts do seu cliente. Você pode seguir o
conselho do @JaromandaX no comentário ou pode remover todos os registros ofensivos com algo como
ssh-keygen -R 10.32.81.216
Então você terá que concordar digitando literalmente "sim" à pergunta sobre você tem certeza ou usando um ssh-keyscanutilitário conforme descritona outra resposta. Observe que, embora esta forma de construir o arquivo evite o aviso interativo sobre o MitM,ainda é suscetível ao ataquepelo mesmo motivo, que também é observado na página de manual do ssh-keyscan (e também mencionado várias vezes nos comentários às respostas no link).