vor ein paar Stunden habe ich die IP-Adresse meines Windows-PCs und meines Raspberry Pi geändert. Bis dahin konnte ich mich problemlos per SSH mit dem Pi verbinden. Jetzt erhalte ich beim Verbindungsversuch die Fehlermeldung, dass jemand "etwas Böses" versucht und ich meinen Netzwerkadministrator kontaktieren soll.
Also habe ich ein Backup meiner "known-hosts"-Datei gemacht und eine leere erstellt. Wenn ich mich jetzt per SSH über das Windows-Terminal verbinde, erhalte ich folgende Ausgabe:
Ich habe keine Ahnung, was mir das sagen soll und was ich tun soll. Ich habe den Pi bereits geflasht, aber ohne Erfolg. Egal, ob ich die Netzwerkkonfiguration meines PCs oder des Pi oder beides in der Router-Konfiguration zurücksetze, die Fehlermeldungen bleiben dieselben.
Antwort1
Die Nachricht
jemand versucht "etwas Gemeines"
ist das Ergebnis einer Änderung der IP des Servers.
Dies tritt normalerweise dann auf, wenn der Benutzer known_hostsbeim Client über Informationen zum Server verfügt, Teile der gespeicherten Informationen sich jedoch von den aktuellen Verbindungsparametern unterscheiden (z. B. andere IP mit demselben Hostschlüssel oder umgekehrt), die den Server identifizieren.
Ich denke, Ihr ausgegrauter Hostname ist kein Hostname, sondern eine IP-Adresse. Das Ändern der IP des Servers löste die Meldung aus. Die Verwendung eines Hostnamens hätte dies verhindert.
(um festzustellen, ob Sie eine IP oder einen Hostnamen verwenden, ist es relevant. Aus Datenschutzgründen ersetzen Sie die Informationen daher vorzugsweise, anstatt sie zu entfernen.)
Durch das Löschen der Originaldatei known_hostssollte dieser Fehler behoben und durch die „First Contact“-Meldung mit der Aufforderung zum Hinzufügen des neuen Host-Schlüssels ersetzt worden sein known_hosts.
=> Dies ist nicht Teil Ihres aktuellen Anmeldeproblems.
Das Login-Problem
Das Debug-Protokoll enthält folgende Informationen:
- Sie befinden sich an einem Windows-Client, der OpenSSH_for_Windows_8.1p1 verwendet
- Erlaubte Authentifizierungsmethoden sind
publickeyundpassword - Ihr Client hat mehrere IDs gespeichert, die zum Anmelden per „Publickey-Authentifizierung“ (was versucht wird) verwendet werden könnten.
Aber das Konto auf dem Server verfügt nicht über das Gegenstück zu mindestens einer der verfügbaren IDs/root/.ssh/authorized_keysund alle fünf Anfragen schlagen fehl.
=> Entweder haben Sie diese Authentifizierungsmethode noch nie verwendet oder Sie haben durch das erneute Flashen Ihres Pi-Servers eine bereits vorhandene entfernt und/root/.ssh/authorized_keysdamit Ihre Möglichkeit zur Verwendung dieser Anfragemethode zunichte gemacht. - Wenn die Authentifizierung mit öffentlichem Schlüssel fehlschlägt, versucht SSH die"Passwortauthentifizierung", aber es tritt ein Fehler auf:
read_passphrase: can't open /dev/tty: No such file or directory
=> Offensichtlich„OpenSSH für Windows“weiß nicht, wo der Anmeldedialog ausgegeben werden soll, und schließlich schlägt die Anmeldung nach den drei zulässigen Versuchen fehl.
Subsumierendie aktuellen Informationen in Ihrer Frage sind mir ziemlich sicher:
Vor Deinen fatalen Veränderungen warst Du verbunden überPublickey-Authentifizierung.
Grund:Da Sie keine relevanten Einstellungen am Client und amKennwortauthentifizierungfehlschlägt, muss dieses Problem bereits vor Ihren schwerwiegenden Änderungen vorhanden gewesen sein. Da Sie sich des Problems jedoch nicht bewusst waren, muss die andere mögliche Authentifizierung verwendet worden sein.
Aufgrund des Verlusts des Originals /root/.ssh/authorized_keysauf dem Server kann der Server Ihren Zugriff nicht autorisieren überPublickey-Authentifizierungund alle Anmeldeversuche schlagen fehl.
Lösungen
- Reparieren Sie die Handhabung der Passwort-Authentifizierung unterOpenSSH für Windows.
Da du keine Angaben dazu gemacht hast, wie du die SSH-Verbindung initiierst, kann es dazu keine richtige Antwort geben.
Möglicherweise verwendest du ein GUI-Tool zum Verbinden. Dann reicht es vielleicht, einfach ein Terminalfenster zu öffnen und die Sitzung per Kommandozeile zu starten.
=> Sie sollten eine neue Frage mit mehr Details erstellen, um dieses spezielle Problem zu lösen.
oder
root/.ssh/authorized_keysStellen Sie den auf dem Server wieder her oder erstellen Sie ihn neu .
So fügen Sie einen Schlüssel hinzuauthorized_keys:- Kopieren Sie nur den öffentlichen Schlüssel eines auf Ihrem Windows-Client vorhandenen (oder neu erstellten) Schlüsselpaars
C:\Users\???\.ssh\auf Ihren Server. - Fügen Sie auf dem Server den öffentlichen Schlüssel zum Schlüssel des Benutzers hinzu
authorized_keys:
cat <public_key_file> >> ~/.ssh/authorized_keys - Testen der Anmeldung
- Kopieren Sie nur den öffentlichen Schlüssel eines auf Ihrem Windows-Client vorhandenen (oder neu erstellten) Schlüsselpaars
Zur Variante 2: Wenn Sie Schwierigkeiten haben, physisch auf die lokale Konsole des Servers zuzugreifen, möchten Sie möglicherweise ein Live Linux herunterladen und auf einem USB-Stick installieren, um per Kennwortauthentifizierung eine Verbindung zum Server herzustellen und den öffentlichen Schlüssel erneut anzuwenden.
Bitte beachten Sie:Ramhundbereits erwähnt mit dem BenutzerWurzelfür eine Remote-Verbindung ist keine gute Idee. Besser ist, Sie nehmen einen normalen Benutzer und verwenden ihn, sudoum Root-Rechte zu erhalten.
Antwort2
Ich habe das Problem gefunden. Wenig überraschend lag es an etwas, das ich selbst getan habe.
Die Fehlermeldung mit all den "@"-Symbolen, die mir sagen, dass jemand "etwas Böses" versucht, war ziemlich eindeutig und löschte auch den Inhalt der Datei "known_hosts". Aber dann machte ich den Fehler, mich mit "root" anzumelden, was anscheinend wirklich deaktiviert ist. Außerdem habe ich gerade festgestellt, dass man sich nach dem ersten Bootvorgang nicht mehr mit einem Benutzernamen in Kleinbuchstaben anmelden kann.
Die Anmeldung mit dem Benutzer „Test“ und dem Passwort „Test“ funktionierte nicht, die Anmeldung mit dem Benutzer „Test“ und dem Passwort „Test“ jedoch schon.
Ich schätze, ich habe etwas Neues gelernt.