SSH-Schlüssel auf ZimaOS hinzufügen, wenn der Home-Pfad schreibgeschützt ist

Der Standardschlüsselpfad im Home-Verzeichnis war nicht beschreibbar

Die ursprüngliche ZimaOS-Frage, die im Dezember 2024 veröffentlicht wurde, betraf den üblichen Workflow mit ~/.ssh/authorized_keys. Das schreibgeschützte Layout des Systems verhinderte, dass der Autor diese Datei auf normalem Weg erstellen konnte. Frühe Versuche in diesem Thema führten zu keiner bestätigten, dauerhaften Lösung und sollten daher nicht als fertige Lösung dargestellt werden.

Ein späterer Bericht zu ZimaOS 1.7 verwendete eine Schlüsseldatei unter /etc

Im August 2026 berichtete ein anderes Community-Mitglied über einen funktionierenden Ansatz unter ZimaOS 1.7. Es legte öffentliche Schlüssel in /etc/ssh/authorized_keys ab und wies den SSH-Daemon an, diese Datei zu verwenden. Die wesentliche Konfiguration lautete:

AuthorizedKeysFile /etc/ssh/authorized_keys

Erstellen Sie die Datei mit administrativen Rechten, fügen Sie pro Zeile einen vollständigen öffentlichen Schlüssel hinzu und setzen Sie Berechtigungen, die verhindern, dass andere Benutzer die Datei ändern. Aktualisieren Sie anschließend die Konfiguration des SSH-Servers und starten Sie den SSH-Daemon neu. Da es sich bei dem Beitrag um ein Community-Ergebnis und nicht um eine offizielle Kompatibilitätserklärung handelt, sollten Sie vor Änderungen die tatsächliche Konfigurationsdatei und den Dienstnamen der installierten ZimaOS-Version überprüfen.

Testen Sie die Schlüsselanmeldung, bevor Sie die Passwortauthentifizierung deaktivieren

Lassen Sie die aktuelle SSH-Sitzung geöffnet und behalten Sie während des Tests den Zugriff auf das ZimaOS-Webterminal bei. Öffnen Sie ein zweites Terminal und stellen Sie sicher, dass der öffentliche Schlüssel erfolgreich eine neue Sitzung ermöglicht. Erst nach diesem Test sollten optionale Maßnahmen zur Absicherung in Betracht gezogen werden.

PasswordAuthentication no
KbdInteractiveAuthentication no
UsePAM no
PermitRootLogin no
PermitEmptyPasswords no

Diese Einstellungen haben weitreichendere Auswirkungen als die Änderung des Schlüsselpfads. Werden sie vor einem erfolgreichen Test der Schlüsselanmeldung angewendet, kann der Fernzugriff für die Administration gesperrt werden. Außerdem sind sie möglicherweise nicht für jede Bereitstellung geeignet, insbesondere wenn das System bewusst auf PAM oder einen kontrollierten Root-Anmeldeprozess setzt.

Betrachten Sie das Verfahren als versionsabhängig

Die Diskussion erstreckt sich über fast zwei Jahre, und der bestätigte Bericht nennt ausdrücklich ZimaOS 1.7. Er zeigt nicht, dass dieselben Dateien Upgrades überstehen oder sich in früheren Versionen identisch verhalten. Dokumentieren Sie die Änderung und testen Sie den SSH-Zugriff nach einer Aktualisierung des Betriebssystems erneut.

FAQ

Warum kann ich unter ZimaOS keine ~/.ssh/authorized_keys erstellen?

Im ursprünglichen Fall war dieser Teil des Dateisystems schreibgeschützt. Der spätere Workaround änderte den Speicherort der Schlüssel im Daemon, anstatt zu versuchen, den normalen Pfad im Home-Verzeichnis beschreibbar zu machen.

Wo speicherte die funktionierende Methode für ZimaOS 1.7 die öffentlichen Schlüssel?

Sie verwendete /etc/ssh/authorized_keys und konfigurierte AuthorizedKeysFile so, dass auf diese Datei verwiesen wurde.

Sollte die Passwortauthentifizierung sofort deaktiviert werden?

Nein. Halten Sie zunächst eine Wiederherstellungssitzung verfügbar und überprüfen Sie eine neue, per Schlüssel authentifizierte Anmeldung. Deaktivieren Sie andere Authentifizierungsmethoden erst nach diesem Test und nur, wenn sie zur Zugriffsrichtlinie des Systems passen.