%20und%20wie%20unterscheidet%20er%20sich%20vom%20%C3%B6ffentlich-privaten%20Schl%C3%BCsselpaar%3F.png)
Die Situation ist, dass ich zuvor einen VPS erstellt hatte. Es war alles eingerichtet, Authentifizierung mit privatem und öffentlichem Schlüssel, Root-Login deaktiviert, Passwort-Login deaktiviert. Alles war eingerichtet.
Dann wird dieser Server zerstört und ein neuer Server wird ausgegliedert.
Ich melde mich also ssh -v root@new_server_ip_numberbei dieser neu installierten Linux-Instanz an und das ist, was ich bekomme:
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.
Was ist das für eine SHA256:5OrjMYiYdmoRTDgjsmBfOXun/4FpiClOU6L21gBDPSk.Zeile? Was bedeutet sie?
Denn diese SHA256:5OrjMYiYdmoRTDgjsmBfOXun/4FpiClOU6L21gBDPSk.Nummer/ID ist offensichtlich nicht die gleiche Nummer, die den Linux-Server in meiner Windows- known_hostsDatei identifiziert.
Ich verwende einen Windows-Laptop und PowerShell, um mich bei diesem Server anzumelden. Auf diesem Windows-Rechner
befindet sich eine Datei und ich habe erwartet, dass einige IDs nicht übereinstimmen, da der alte Server zerstört und der neue erstellt wurde. Ich habe den Schlüssel bereits gelöscht und durch diesen Schlüssel des neu installierten Linux-Servers ersetzt. Aber der SSH-Client lässt mich nicht rein. So sieht meine aktuelle Datei aus:C:\Users\roeslermichal\.ssh\known_hosts10.32.81.216 ssh-rsa10.32.81.216 ssh-rsa:\Users\roeslermichal\.ssh\known_hosts
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=
Aber ich weiß nicht wirklich, was diese Host-Schlüssel sind, weil ich auf diesem neuen Linux-Server keine Schlüssel erstellt habe. Die Anmeldung als Root war die erste Aktion, die ich bezüglich dieses neu erstellten Linux-Servers durchgeführt habe. Und es gibt bereits einige host_keysauf diesem Server.??? Und dies sind keine privaten und öffentlichen SSH-Schlüssel, weil ich sie noch nicht erstellt habe. Was sind also diese Schlüssel, die generiert wurden und meinen neuen Linux-Server in der Windows- known_hostsDatei identifizieren?
Ich habe gelesendieser Threadhabe es ein paar Mal sorgfältig durchgesehen, aber verstehe die dort gegebenen Antworten nicht ganz und warum sie funktionieren. Noch mehr verstehe ich nicht, warum ich mich nicht bei meinem neu erstellten Linux-Server anmelden kann, obwohl ich den alten Server-RSA-Hostschlüssel durch einen neuen Server-RSA-Hostschlüssel ersetzt habe.
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=
10.32.81.216 ssh-ed25519Obwohl ich den Nor- Schlüssel nicht ersetzt habe 10.32.81.216 ecdsa-sha2-nistp256. Kann das der Grund sein, warum ich mich nicht anmelden kann?
Antwort1
Bei SSH gibt es eine gegenseitige Authentifizierung.
Zuerst dieKlientauthentifiziert, dass der Server tatsächlich derjenige ist, mit dem er eine Verbindung herstellen wollte. Dazu merkt er sich den öffentlichen Teil des Host-Schlüsselpaars in der ~/.ssh/known_hostsDatei. Er erfährt dies entweder während der ersten Verbindung (das ist genau der Teil, in dem Sie aufgefordert werden, „Ja“ einzugeben) oder erfährt möglicherweise vom DNS, ob es den SSHFP-Eintrag für den Host enthält und die Zone DNSSEC-geschützt ist. Wenn der Client feststellt, dass der Server den falschen Schlüssel präsentiert, wird er die Verbindung normalerweise ablehnen und einen laufenden MitM-Angriff behaupten.
Dafür ist das SSH-Host-Schlüsselpaar da. Grob gesagt ist es die SSH-Version der PKI-Infrastruktur, wenn auch keine CA-basierte (oder es verwendet DNSSEC, um eine CA-ähnliche Vertrauenskette zu implementieren); es ist wie das HTTPS-Zertifikat/Schlüsselpaar (mit dem Zweck „Webserver-Authentifizierung“) und dient demselben Zweck. EsIstdas asymmetrische („öffentlich-private“) Schlüsselpaar, das zu einem Server gehört.
Zweitens, dieServerauthentifiziert, dass der Client wirklich der ist, der er vorgibt zu sein. Dafür kann es ein Benutzername/Passwort-Paar oder eine beliebige komplexe Chat-basierte Authentifizierung oder das asymmetrische Schlüsselpaar verwenden, das auf dem Server in users gespeichert ist ~/.ssh/authorized_keys. Dieses Mal gehört das Schlüsselpaar einem Benutzer. Auch hier hat die traditionelle CA-basierte PKI ein „Analogon“, nämlich Client-Zertifikate (mit dem Zweck „Web-Client-Authentifizierung“).
Sehen Sie diese Zeile in Ihrer Ausgabe Someone could be eavesdropping on you right now (man-in-the-middle attack)!? So wird der MitM-Angriff gemeldet, den es verhindern soll. Wahrscheinlich ist es übervorsichtig, aber das ist Ihre Sicherheit.
Wenn du bistabsolut sicherEs liegt kein Angriff vor und der neue Fingerabdruck ist der richtige. Entfernen Sie einfach die fehlerhafte Zeile aus der known_hosts-Datei Ihres Clients. Sie können dem
Rat von @JaromandaX im Kommentar folgen oder alle fehlerhaften Datensätze mit etwas wie
ssh-keygen -R 10.32.81.216
Dann müssen Sie zustimmen, indem Sie auf die Frage, ob Sie sicher sind, wörtlich "ja" eingeben oder ein ssh-keyscanDienstprogramm wie beschrieben verwendenin der anderen Antwort. Beachten Sie, dass diese Art der Dateierstellung zwar die interaktive Warnung zu MitM vermeidet,es ist immer noch anfällig für den Angriffaus demselben Grund, der auch in der Manualpage von ssh-keyscan vermerkt ist (und auch in Kommentaren zu den Antworten unter dem Link mehrfach erwähnt wird).