Entwicklertools · Chmod-Rechner
SSH-Berechtigungen zu offen: die genauen Modi, die ~/.ssh benötigt und warum
· Warum es wichtig ist
chmod Unix Zugriffskontrolle
OpenSSH lehnt Schlüssel und Authorized_Keys-Dateien ab, die andere Benutzer lesen oder ändern könnten. Dieser Beitrag listet die erwarteten Modi auf, erklärt die StrictModes-Prüfung und zeigt, wie man sie überprüft.
Berechtigungen 0644 für id_ed25519 sind zu offen – der Schlüssel, der gestern funktionierte, wird nach einer Kopie auf einen neuen Computer abgelehnt
Ein kopierter privater Schlüssel mit Modus 0644 dekodiert zu rw-r--r--. Der Eigentümer kann es lesen und ändern, während die Gruppe und andere es lesen können. Die Voreinstellung „600 private-file“ rendert stattdessen rw------- und lässt diese Klassen leer. Dieser gibt die Bits genau an, kann aber nicht nachweisen, warum ein SSH-Client den Schlüssel akzeptiert oder abgelehnt hat.
Vergleichen Sie den beobachteten Modus mit der privaten Voreinstellung. Die Eingaben 0644, 644 und 0o644 sind gleichwertig, und durch den Wechsel zu 600 werden Gruppen- und andere Lesevorgänge entfernt, während die Lese- und Schreibvorgänge des Besitzers erhalten bleiben. Der generierte Befehl ist inert. Clientverhalten, Eigentum, ACLs und Speichersemantik erfordern Beweise, die über diesen Konverter hinausgehen.
Warum der Client überhaupt prüft – ein für andere lesbarer privater Schlüssel ist nicht mehr privat, daher weigert sich ssh, ihm zu vertrauen
Das Repository bezeichnet 600 als „private Datei“ und beschreibt den Zugriff nur für Eigentümer. Seine Arithmetik unterstützt diese Beschreibung: 6 gewährt dem Besitzer Lese- und Schreibrechte, während beide Nullen normale Berechtigungen von Gruppen und anderen entfernen. Das symbolische Ergebnis ist rw-------. Dies beweist, dass die Zuschüsse im Modus fehlen, und nicht, dass ein Kunde sie akzeptiert.
In den Quellen wird keine OpenSSH-Implementierungs-, Handbuch-, Konfigurations- oder Laufzeitmeldung angezeigt, daher kann die Voreinstellung keine Ablehnungsrichtlinie festlegen. Der Rechner verspricht weder, dass ein Modus jeden Fehler behebt, noch validiert er wichtige Inhalte. Es zeigt zuverlässig an, ob ein Kandidat über die Eigentümerklasse hinaus Lese-, Schreib- oder Ausführungsmöglichkeiten bietet, und nicht mehr.
Das Repository bezeichnet 600 als privat; Die Client-Ablehnungsrichtlinie erfordert OpenSSH-Beweise
Das StrictModes-Verhalten wird hier weder implementiert noch überprüft. Der Browser verfügt über keinen SSH-Server, keine Überprüfung des Home-Verzeichnisses, keine Eigentumssuche und keine Konfigurationseingabe. Es kann nicht wissen, ob „authorized_keys“ konsultiert wird, ob eine andere Identität ein Verzeichnis schreiben kann oder ob eine Einstellung zutrifft. Durch den Wechsel in einen Modus wird eine Konvertierung durchgeführt, keine Daemon-Entscheidung oder Dateisystemprüfung.
Genaue Bits und genaue Richtlinien sind separate Fragen. Modus 600 beweist rw-------, während 700 rwx------ beweist. Weder werden Eigentümer identifiziert, übergeordnete Verzeichnisse überprüft noch ein Daemon modelliert. Sammeln Sie Serverdokumentation und Dateisystembeweise unabhängig voneinander und verwenden Sie dann den Rechner, um Beobachtungen zu entschlüsseln, ohne die Ausgabe als StrictModes-Urteil oder vollständige Sicherheitsüberprüfung darzustellen.
Das StrictModes-Verhalten ist hier nicht implementiert oder überprüft
Die Modi 600 und 700 sind ausgelieferte private Voreinstellungen. Der Modus 600 gewährt einem regulären Dateieigentümer Lese- und Schreibzugriff, ohne Gruppen- oder andere Berechtigungen. Der Modus 700 fügt Owner Execute für ein Verzeichnis hinzu und ermöglicht so den Zugriff auf eingegebene und benannte Inhalte, während andere Klassen nichts über gewöhnliche Bits erhalten. Der Rechner kennt noch keinen tatsächlichen Besitzer.
Andere SSH-bezogene Dateiregeln bleiben extern. Obwohl öffentliche Schlüssel und autorisierte Schlüssel relevant sein können, stellt das Repository keine verifizierten Anforderungen dafür bereit. Der Rechner kann 644 als rw-r--r-- dekodieren, kann aber die SSH-Akzeptanz nicht zertifizieren. Jede umfassendere Anforderungstabelle erfordert maßgebliche OpenSSH-Beweise, die in diesen Quellen und im vorhandenen Artikel fehlen.
600 und 700 sind ausgelieferte private Voreinstellungen; andere SSH-Dateiregeln bleiben extern
Ein unterstütztes Beispiel konvertiert Auflistungszeichenfolgen, ohne ein Verzeichnis zu überwachen. Wenn die externe Ausgabe -rw-r--r-- anzeigt, gibt der Parser 644 zurück; Wenn rw------- angezeigt wird, wird 600 zurückgegeben. Die Matrix hebt die geänderten Gruppenlese- und anderen Lesefelder hervor. Dadurch werden Transkription und Arithmetik überprüft, während Pfad, Eigentum und Herkunft der Auflistung ungeprüft bleiben.
Verzeichniszeichenfolgen funktionieren ähnlich. Ein bereitgestelltes drwx------ wird zu 700, da das erkannte Typzeichen vor dem Parsen von neun Berechtigungspositionen entfernt wird. In der Zusammenfassung kann ein Verzeichnispräfix angezeigt werden. Die Seite listet weder ~/.ssh auf noch erkennt sie Dateien, Besitzer oder ACL-Indikatoren, daher darf diese Konvertierung nicht als Audit bezeichnet werden.
Arbeitsbeispiel: Kopierte Moduszeichenfolgen konvertieren, ohne das Verzeichnis zu prüfen
Der Modusverlust bei Übertragungstools und Dateisystemen liegt außerhalb der Repository-Beweise. Keine Quelle kopiert Dateien, öffnet Archive, stellt Speicher bereit oder vergleicht Metadaten standortübergreifend. Der Rechner kann einen beobachteten 644 nicht einer Freigabe, einem Laufwerk, einem Initialisierungssystem oder einem Archivierungsdienstprogramm zuordnen. Es sieht nur den in seinem Feld eingegebenen Modus, ohne Übertragungsverlauf.
Wenn ein kopiertes Element einen unerwarteten Modus hat, vergleichen Sie erwartete und beobachtete Werte, ohne Schuldzuweisungen vorzunehmen. Zwischen 600 und 644 bleiben die Besitzerberechtigungen unverändert, während Gruppen-Lesen und Andere-Lesen angezeigt werden. Der Konverter unterstützt genau dieses Delta. Um festzustellen, ob die Übertragung, die Erhaltung oder die Erholung die Ursache dafür ist, sind Nachweise über den Bestimmungsort und den Übertragungsweg erforderlich.
Der Modusverlust bei Übertragungstools und Dateisystemen liegt außerhalb des Repository-Beweises
Schlüsselformat, Agentenstatus und Serverprotokolle fallen nicht in diesen Rechner. Es analysiert oktale und symbolische Berechtigungstexte, niemals private Schlüssel, SSH-Agent-Daten oder Protokolle. Eine gültige 600-Konvertierung sagt nichts über kryptografisches Material, geladene Identitäten, Netzwerkaustausch oder Serverantwort aus. Es beweist, dass nur der Besitzer mit leeren Gruppen und anderen Klassen liest und schreibt.
Diese Grenze verhindert, dass jeder SSH-Fehler als chmod-Arbeit behandelt wird. Wenn ein beobachteter Modus von der privaten Voreinstellung abweicht, zeigt der Rechner genaue Bits an; Wenn es bereits übereinstimmt, bietet die Route keinen weiteren SSH-Nachweis. Fahren Sie mit der externen Diagnose fort, anstatt den Zugriff zu erweitern. Bei einer erfolgreichen Konvertierung handelt es sich nicht um eine Authentifizierung, und die Vorschau führt nichts aus.
Fazit: Privat bedeutet 600 und 700 – und der Rechner bestätigt, dass ein Modus, den Sie gerade einstellen, der Gruppe oder anderen nichts bringt
Die vom Repository unterstützte Erkenntnis ist, dass 600 und 700 normale Berechtigungen für den Eigentümer reservieren. Ihre symbolischen Formen rw------- und rwx------ enthalten keine Gruppen- oder anderen Zuwendungen. Oktaler, symbolischer Text, Kontrollkästchen und eine Zusammenfassung überprüfen diese Darstellungen, während fehlerhafte Positionen abgelehnt werden. Nichts davon beweist die SSH-Akzeptanz, den Besitz, die Schlüsselgültigkeit oder die Authentifizierung.
Wandeln Sie die Konvertierung nicht in eine universelle SSH-Richtlinie um. Die Route implementiert keine StrictModes, überprüft keine Home-Verzeichnisse, identifiziert keine Besitzer und validiert keine Schlüsseldateien. Verwenden Sie es, um leere Gruppen und andere Klassen zu bestätigen, und verlassen Sie sich dann auf verlässliche SSH-Beweise und das tatsächliche System. Durch das Kopieren eines angezeigten Befehls wird die Verantwortung auf die Shell und das Dateisystem übertragen.