Ich habe die übliche Vorgehensweise befolgt und die Anmeldung bei Debian nur mit öffentlichem Schlüssel und SSH zugelassen. Dann habe ich aus Versehen die Berechtigung für den Ordner ~/.ssh/ geändert (ich glaube, er gehörte root). Danach hat sich openSSH geweigert, mich anzumelden! (und der Server war in einem anderen Land und hatte keine Remote-/KVM-Konsole.)
Ich finde dieses Setup ziemlich fragil. Gibt es eine Möglichkeit, dies zu verhindern und mir vielleicht einfach beim nächsten Login eine Warnung zu geben?
Wenn es keine Lösung gibt, muss ich als Backup ein sicheres Anmeldekennwort einrichten, egal was alle anderen sagen.
Habe eine ähnliche Frage zur Sperrung gefunden, aber die Grundursache war eine Änderung der Iptable/Konfiguration: Verhindern Sie, dass Sie beim Konfigurieren von SSH und iptables ausgesperrt werden Ich habe die Konfiguration nicht geändert und daher nicht mit einer Sperre gerechnet.
Antwort1
Hosts benötigen eine alternative Zugriffsmethode, wenn sie wiederhergestellt werden sollen. SSH über das Internet erfordert, dass alles normal funktioniert: Netzwerkzugriff, Firewall-Zulassungsregel, laufendes und konfiguriertes SSHD, gesicherte Schlüsseldateien. Wenn eines davon unterbrochen wird, kann kein Zugriff erfolgen. Der zuverlässigste Out-of-Band-Zugriff ist nicht auf die Funktionsfähigkeit des IP-Netzwerks im Host angewiesen.
Wenn es sich um eine VM handelt, fahren Sie sie vielleicht herunter und schließen Sie die Festplatte an eine andere funktionierende Instanz an, um sie zu reparieren. Nicht ideal, erfordert aber nur, dass Sie Zugriff auf die Festplatte haben.
Eine Off-Host-Sicherung der Daten ermöglicht die Erstellung eines neuen Ersatzhosts. Es mag albern erscheinen, nur weil der SSH-Zugriff verloren gegangen ist, zu zerstören und neu aufzubauen, aber es bleibt eine Wiederherstellungsoption.
Um das Problem von vornherein zu verhindern, sshd -T -fwird eine Syntaxprüfung der SSHD-Konfiguration (für OpenSSH) nicht alles aufdecken. Ein End-to-End-Test könnte durchgeführt werden, indem man einen anderen SSHD auf einem anderen Port startet, bei dem alles gleich ist, außer der Portnummer. Stellen Sie eine Remoteverbindung damit her, um zu testen, ob alles funktioniert. Leider werden selbst mit dieser Sorgfalt unbeabsichtigte Dinge nicht aufgedeckt, wie etwa eine Berechtigungsänderung in Home-Verzeichnissen, die versehentlich SSH-Dateien ungesichert macht. Oder eine IP-Änderung, die die Wirksamkeit ssh_configaufgrund von MatchSchlüsselwörtern verändern könnte.
Passwörter bleiben weiterhin ein furchtbarer Authentifizierungsmechanismus.