Publickey funktioniert plötzlich nicht mehr
Hallo,
habe heute plötzlich eine Email von einen meiner Server bekommen, darin stand folgendes:
Aus irgendeinem Grund und aus völlig heiterem Himmel, hat Linux beschlossen nicht mehr mit dem Publickey zu funktionieren. Ich kann es mir irgendwie nicht erklären.
Habe dann den Host versucht rauszuwerfen:
Dann wieder hinzufügen mit:
Diese Ausgabe dann:
Danach kann ich mich aber immer noch nicht ohne Passwort einloggen. Verstehe das irgendwie nicht, da der Server als auch der Host auf den zugegriffen werden soll, seit mehreren Wochen nicht angefasst wurde. Einfach weil alles ohne Probleme lief.
Von dem Server greife ich auch noch auf andere Systeme ohne Passwort zu und da gibt es keine Probleme. Die Berechtigungen der authorized_keys ist 600, das habe ich gleich als erstes überprüft und sollte passen.
Würde mich über Hilfe sehr freuen.
Gruß
habe heute plötzlich eine Email von einen meiner Server bekommen, darin stand folgendes:
Permission denied, please try again.
Permission denied, please try again.
Permission denied (publickey,password).Aus irgendeinem Grund und aus völlig heiterem Himmel, hat Linux beschlossen nicht mehr mit dem Publickey zu funktionieren. Ich kann es mir irgendwie nicht erklären.
Habe dann den Host versucht rauszuwerfen:
ssh-keygen -R HostnameDann wieder hinzufügen mit:
ssh-copy-id HostnameDiese Ausgabe dann:
root@server:~# ssh-keygen -R Hostname
# Host Hostname found: line 18
/root/.ssh/known_hosts updated.
Original contents retained as /root/.ssh/known_hosts.old
root@server:~# ssh-copy-id Hostname
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/root/.ssh/id_rsa.pub"
The authenticity of host 'Hostname (IP_Adresse)' can't be established.
ECDSA key fingerprint is SHA256:
Are you sure you want to continue connecting (yes/no)? yes
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
root@Hostname's password:
Number of key(s) added: 1
Now try logging into the machine, with: "ssh 'Hostname'"
and check to make sure that only the key(s) you wanted were added.Danach kann ich mich aber immer noch nicht ohne Passwort einloggen. Verstehe das irgendwie nicht, da der Server als auch der Host auf den zugegriffen werden soll, seit mehreren Wochen nicht angefasst wurde. Einfach weil alles ohne Probleme lief.
Von dem Server greife ich auch noch auf andere Systeme ohne Passwort zu und da gibt es keine Probleme. Die Berechtigungen der authorized_keys ist 600, das habe ich gleich als erstes überprüft und sollte passen.
Würde mich über Hilfe sehr freuen.
Gruß
Kommentieren
Teilen
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 392747
Url: https://administrator.de/forum/publickey-funktioniert-ploetzlich-nicht-mehr-392747.html
Ausgedruckt am: 21.05.2025 um 16:05 Uhr
8 Kommentare
Neuester Kommentar
Moin,
ist der key vielleicht abgelaufen?
Liebe Grüße
Erik
ist der key vielleicht abgelaufen?
Liebe Grüße
Erik
Dann wäre es aber mit dem obengenannten Verfahren gelöst gewesen. Des weiteren gibt es bei ssh keys keine Gültigkeit.
Moin,
Public/Private Keys habe kein Ablaufdatum. Dafür braucht es ein Zertifikat.
Was sagt das SSH bzw. auth Log?
Edit: Sehe gerade dass du dich mit root versuchst anzumelden. Per Default ist der Zugriff mit root per SSH in der Konfiguration verboten. Das sollte man auch nicht ändern. Erstelle einen User und gebe diesen die notwendigen Berechtigungen via sudo. (Nicht den User nur in die Gruppe sudo verschieben! Wirklich Regeln in der sudoers Datei erstellen!)
Viele Grüße
Exception
ist der key vielleicht abgelaufen?
Public/Private Keys habe kein Ablaufdatum. Dafür braucht es ein Zertifikat.
Was sagt das SSH bzw. auth Log?
Edit: Sehe gerade dass du dich mit root versuchst anzumelden. Per Default ist der Zugriff mit root per SSH in der Konfiguration verboten. Das sollte man auch nicht ändern. Erstelle einen User und gebe diesen die notwendigen Berechtigungen via sudo. (Nicht den User nur in die Gruppe sudo verschieben! Wirklich Regeln in der sudoers Datei erstellen!)
Viele Grüße
Exception
Zitat von @129580:
Moin,
Public/Private Keys habe kein Ablaufdatum. Dafür braucht es ein Zertifikat.
Was sagt das SSH bzw. auth Log?
Viele Grüße
Exception
Moin,
ist der key vielleicht abgelaufen?
Public/Private Keys habe kein Ablaufdatum. Dafür braucht es ein Zertifikat.
Was sagt das SSH bzw. auth Log?
Viele Grüße
Exception
Der sagt:
samba sshd[15594]: Authentication refused: bad ownership or modes for directory /root
samba sshd[15594]: Connection closed by Server-Adresse port 48264 [preauth]Versteh ich nicht. Wie kann sich die Ownership einfach so ändern? Hat Sie eigentlich auch nicht.
Ich habe den Fehler vermutlich gefunden. Obwohl es eher die Ursache ist. Auf dem ZielHost das "/root" wurde als Ownership folgendes gesetzt:
Eigentümer 4061
Group 401
Irgendwann heute Nacht. Wie kann bitte soetwas passieren?
Eigentümer 4061
Group 401
Irgendwann heute Nacht. Wie kann bitte soetwas passieren?
Zitat von @Fenris14:
Ich habe den Fehler vermutlich gefunden. Obwohl es eher die Ursache ist. Auf dem ZielHost das "/root" wurde als Ownership folgendes gesetzt:
Eigentümer 4061
Group 401
Irgendwann heute Nacht. Wie kann bitte soetwas passieren?
Ich habe den Fehler vermutlich gefunden. Obwohl es eher die Ursache ist. Auf dem ZielHost das "/root" wurde als Ownership folgendes gesetzt:
Eigentümer 4061
Group 401
Irgendwann heute Nacht. Wie kann bitte soetwas passieren?
Normalerweise gar ncht. Berechtigungen von Verzeichnissen kann und darf nur der Besitzer festlegen. Den Eigentümer und Gruppe darf nur Root definieren. Und das root Verzeichnis gehört nur root - logisch. Ich würde den Server dringend vom Netz nehmen. Klingt für mich nach einer Infektion, was auch kein Wunder wäre, bei eurer Sicherheit...
Erstmals das Teil vom Netz nehmen.
Anschließend würd ich mal prüfen, welcher User und welche Gruppe das ist. Und anschließend die System Logs analysieren.
Zitat von @129580:
Klingt für mich nach einer Infektion, was auch kein Wunder wäre, bei eurer Sicherheit...
Klingt für mich nach einer Infektion, was auch kein Wunder wäre, bei eurer Sicherheit...
Was soll das wieder heißen? Soweit ich weiß ist es gängige Praxis Publickeys bei SSH zu verwenden und auch nicht ungewöhnlich. Sogar noch besser als der Login mit Passphrase, selbst wenn es 100 beliebige Zeichen besitzen würde.
Keine Ahnung wie ihr das bei euch macht, aber viele Möglichkeiten gibt es da nicht. Ich mach zum Beispiel die Backups per Rsync und da kommt man um Publickey gar nicht herum, wenn man es per Script ausführt. Des weiteren sind die Rechner nur im lokalen Netzwerk erreichbar.
Was soll das wieder heißen? Soweit ich weiß ist es gängige Praxis Publickeys bei SSH zu verwenden und auch nicht ungewöhnlich. Sogar noch besser als der Login mit Passphrase, selbst wenn es 100 beliebige Zeichen besitzen würde.
Bezüglich der Verwendung des Public/Private Key Auth Verfahren habe ich doch gar nichts gesagt? Ganz im Gegenteil. Public/Private Key Auth sollte man grundsätzlich verwenden statt Password Auth. Allerdings sollte man anschließend Password Auth in der SSHD Konfig deaktivieren. Ansonsten bringt das nichts und das wurde bei deinem Server wohl nicht gemacht, da du ja sprichst, dass du dich via SSH mit einem Password erfolgreich anmelden konntest. Zumindest habe ich das so interpretiert. Wäre auf jeden Fall die Erklärung, wieso der Brute Force Angriff erfolgreich war, wenn keine weiteren Maßnahmen z:B. Fail2ban vorhanden sind. (Falls es ein Angriff war. Könnte ja auch einer deiner Kollegen gewesen sein - siehe unten)
Keine Ahnung wie ihr das bei euch macht, aber viele Möglichkeiten gibt es da nicht.
Was ich kritisiert habe, dass du offensichtlich mit dem User "root" (UID 0) arbeitest und auch mit diesem via SSH dich anmeldest. Das sollte man unbedingt vermeiden. Bei den meisten gängigen Distributionen ist deshalb bei der SSHD Konfiguration der Parameter "PermitRootLogin" per Default auf "no" gesetzt. Man sollte immer nur mit normalen Usern arbeiten und auf ein System zugreifen. Die Rechtezuteilung des Users macht man via sudo. In der Windows Welt wird das genauso gemacht. Somit sollte das jeder Admin eigentlich wissen. Insbesondere für ein Linux Spezialisten.
Wie bereits oben schon geschrieben, kann nur der Superuser (UID 0), den Eigentümer oder Gruppe eines Verzeichnisses ändern. Das Verzeichnis /root ist das Homeverzeichnis des Superusers und logischerweise ist er der Eigentümer. Wenn also sich bei diesem Verzeichnis der Eigentümer und die Gruppe sich geändert hat, dann wurde das mit dem root User durchgeführt. Entweder von einem deiner Kollegen oder durch eine Fremde Person. Wenn letzteres, dann ist dein System kompromittiert. Und wenn es einer deiner Kollegen war, dann diesen in eine Linux Nachschulung schicken. An dem Verzeichnis darf/sollte niemand rumbasteln.
Von alleine wird nicht der Eigentümer oder Gruppe eines Verzeichnis oder einer Datei geändert. Genauso wenig wie die Rechte. Das wäre ja fatal...
Edit:
Des weiteren sind die Rechner nur im lokalen Netzwerk erreichbar.
ah okay. Dann passt das zumindest. Trotzdem gilt das was ich oben geschrieben habe.
Dann würde ich mal schauen, wer von deinen Kollegen letzte Nacht auf dem Server aktiv war. Wie gesagt, von alleine ändern sich Eigentümer und Gruppe nicht. Außer ihr habt ein Shell Script geschrieben, welches dann mit root Rechten gestartet wurde. Aber wenn ihr solch ein Script ungetestet auf ein produktives System ausführt und dieses auch noch ein solch gravierender Fehler enthält....
Hast du inzwischen mal nachgeschaut welcher User/Gruppe hinter den IDs stecken?
