☰

Wie verhindere ich, dass Benutzer ihren eigenen .ssh-Ordner manipulieren?

tag-icon • tag-icon permissions ssh-keys
Wie verhindere ich, dass Benutzer ihren eigenen .ssh-Ordner manipulieren?

Ich verwalte einen RedHat-Server, bei dem sich Benutzer über SSH mit einer auf privaten/öffentlichen Schlüsseln basierenden Authentifizierung anmelden.

Ich möchte verhindern, dass sie versehentlich den Inhalt ihrer~/.sshOrdner. Einige von ihnen haben bereits ihren gesamten Home-Ordner rekursiv mit 777-chmod geändert, weil „es so einfacher war, Dateien mit Kollegen zu teilen“ und sich damit selbst ins Bein geschossen.

Irgendeine Idee, wie ich das erreichen kann? Vorzugsweise mit dem Standardberechtigungssystem von Linux.

Antwort1

Die kurze Antwort lautet: Das können Sie nicht.

SSH ist sehr wählerisch, was Berechtigungen angeht, und spielt nicht mit Dateien, deren Aussehen ihm nicht gefällt. Außerdem ssh_configwerden die Benutzer analysiertVordie systemweite Konfiguration.

AllerdingsMaiEs wäre möglich, die Dateien woanders abzulegen und das Verzeichnis für jeden Benutzer als schreibgeschütztes Dateisystem bereitzustellen $HOME/.ssh. (Das ist möglich – aber ich weiß nicht, wie SSH und zugehörige Tools damit umgehen würden.)

Einige von ihnen haben bereits rekursiv ihren gesamten Home-Ordner mit 777-chmoded versehen

Dann haben Sie viel größere SICHERHEITS- und Schulungsprobleme.

Antwort2

Es ist schwierig, Benutzer vor ihrer eigenen Unwissenheit und Inkompetenz zu schützen.

Aber je nachdem, wie viel Selbstverwaltung Sie Ihren Benutzern überlassen müssen und wie viel Sie für sie verwalten: Sie können sshd so konfigurieren, dass an einem alternativen Speicherort außerhalb ihres Home-Verzeichnisses und anderswo als nach Schlüsseln gesucht wird ~/.ssh/authorized_keys.

AutorisierterSchlüsselbefehl

Eine relativ aufwendige Lösung ist die/etc/ssh/sshd_config AuthorizedKeysCommand Direktive, die sich nicht auf authorized_keys-Dateien verlässt, sondern ein Programm angibt, das zum Nachschlagen der öffentlichen Schlüssel des Benutzers verwendet werden soll, beispielsweise in:

  • ALDAP-Verzeichnis

  • ADatenbank

  • ein (trivialer) Webservice

  • oder wenn Ihre Benutzernamen mit den Benutzernamen von Github identisch sind, können Sie Benutzern die Authentifizierung mit den Schlüsselpaaren erlauben, die sie dort hochgeladen haben:

    AuthorizedKeysCommand /usr/bin/curl https://github.com/%u.keys

Wie erwähnt indiese Antwort; Sie müssen eine geeignete SELinux-Richtlinie für den AuthorizedKeysCommand erstellen, da dieser von den Standardrichtlinien blockiert wird.

Mir gefällt dieser Ansatz, da er viele Probleme im Zusammenhang mit der Verwaltung autorisierter Schlüssel lösen kann: Er ermöglicht eine zentrale Verwaltung, beseitigt das Henne-Ei-Problem, autorisierte Schlüssel auf Server zu bringen, wenn Sie die Kennwortauthentifizierung in SSH deaktivieren möchten, und mehr.
Er nutzt die Tatsache aus, dass öffentliche Schlüssel nicht besonders sensibel sind (im Gegensatz zu den zugehörigen privaten Schlüsseln), sodass die zentrale Verwaltung meiner Meinung nach kein zusätzliches Risiko darstellt und wahrscheinlich sogar Ihre Kontroll- und Berichtsfunktionen verbessert.

AutorisierteSchlüsseldatei

Etwas weniger komplex ist es, Schlüssel in einem Verzeichnis außerhalb ihres Home-Verzeichnisses zu speichern. Verwenden Sie beispielsweise /etc/ssh/<username>(ersetzen Sie es <username>durch ihren tatsächlichen Benutzernamen). Dieses Verzeichnis sollte über 755 Berechtigungen verfügen und dem Benutzer gehören. Verschieben Sie die authorized_keysDatei dorthin. Die Datei authorized_keys sollte weiterhin über 644 Berechtigungen verfügen und dem Benutzer gehören.

In/etc/ssh/sshd_configverstelle dieAuthorizedKeysFileEinstellung

AuthorizedKeysFile    /etc/ssh/%u/authorized_keys

Und starten Sie den SSH-Daemon neu

Antwort3

Die beste Lösung, die mir einfällt, ist, sie .sshals authorized_keysRoot-Eigentümer zu erstellen.

Root-eigene .ssh / autorisierte Schlüssel

SSH ist bei Berechtigungen wählerisch, aber nicht unangemessen. Erstens erfordert es, dass der Benutzer selbst Lesezugriff auf hat authorized_keys(was Lesezugriff auf alle übergeordneten Verzeichnisse erfordert). Zweitens verweigert es den Zugriff, wenn ein anderer Benutzer als der Benutzer selbst oder root Schreibzugriff auf /home, .ssh, oder hat authorized_keys. Dies verbietet o+w, und g+wfür eine Gruppe, die andere Benutzer enthält.

Dieses Setup funktioniert bei mir, der Benutzer kann sich anmelden:

drwxr-xr-x 19 root root 4096 Sep 22 11:24 /
drwxr-xr-x  3 root root 4096 Sep 22 11:19 /home/
drwx------ 14 test test 4096 Sep 22 11:44 /home/test/
drwxr-x---  2 root test 4096 Sep 22 11:42 /home/test/.ssh/
-rw-r--r--  1 root test   98 Sep 22 11:36 /home/test/.ssh/authorized_keys

Da .sshund authorized_keysdem Root-Benutzer gehören, kann der Benutzer die Berechtigungen für sie weder ändern noch entfernen. Außerdem können sie ihre eigenen authorized_keysDateien nicht bearbeiten.

Wenn Sie dem Benutzer das Bearbeiten seiner erlauben möchten authorized_keys, können Sie Gruppen-Schreibrechte hinzufügen. Dies erfordert, dass die testGruppe keine anderen Mitglieder außer testsich selbst hat:

-rw-rw-r--  1 root test   99 Sep 22 12:04 /home/test/.ssh/authorized_keys

Bei beiden Ansätzen kann der Benutzer keine eigenen Dateien mehr unter erstellen .ssh. Daher sollten Sie ihm möglicherweise auch einige zusätzliche Dateien zur Verfügung stellen. Einige, die mir einfallen, sind: known_hosts, config, und id_rsa{.pub,}oder andere Schlüsseltypen.

Alternative: chattr

Einige Linux-Dateisysteme unterstützenDateiattribute, insbesondere eineunveränderliche Flagge. Dateien/Verzeichnisse mit dem gesetzten Flag „unveränderlich“ können nicht gelöscht, geändert oder deren Berechtigungen geändert werden. Nur Root kann dieses Flag setzen/löschen.

Dieser Befehl würde auch mit den Standardeigentümer-/Berechtigungseinstellungen funktionieren:

# chattr +i ~test/.ssh/{authorized_keys,}

Jetzt .sshund authorized_keyskann in keiner Weise geändert werden, nicht einmal von root. Wenn root diese Dateien aktualisieren muss, müssen Sie chattr -idies zuerst tun. Verwenden Sie, lsattrum nach Attributen zu suchen.

Dieser Ansatz ist einfacher, aber weniger flexibel. Er erfordert auch Dateisystemunterstützung; ich glaube, er wird zumindest auf ext2/3/4, XFS und btrfs unterstützt.

Posix-ACLs?

Es gibt auchPosix-ACLs(Access Control Lists), die eine etwas feinere Kontrolle ermöglichen. Ich bin damit nicht so vertraut und bin mir nicht sicher, ob sie hier hilfreich sind.

Strenge Modi

Notiz:wird dringend abgeraten, ist aber der Vollständigkeit halber aufgeführt.

Der OpenSSH-Serverhat eine Konfigurationsanweisunggenannt StrictModes, das bestimmt, wie wählerisch SSH bei Berechtigungen ist:

Gibt an, ob sshd die Dateimodi und Eigentümerschaft der Dateien und des Home-Verzeichnisses des Benutzers prüfen soll, bevor die Anmeldung akzeptiert wird. Dies ist normalerweise wünschenswert, da Anfänger manchmal versehentlich ihre Verzeichnisse oder Dateien für alle schreibbar machen. Der Standardwert ist yes.

Wenn Sie diese Option deaktivieren, haben Sie mehr Freiheiten bei der Einrichtung von Eigentumsrechten und Berechtigungen. Allerdings ist SSH standardmäßig aus guten Gründen streng. Ein Benutzer, der seine SSH-Dateien mit 777-chmodding modifiziert, stellt ein Sicherheitsrisiko dar.

Antwort4

Führen Sie jede Nacht einen Cron-Job aus, um die Berechtigungen zu korrigieren.

Das Löschen von Dateien ist etwas schwieriger. Möglicherweise können Sie fehlende Dateien auch aus einem Backup von Cron wiederherstellen. Aber es scheint, als könnten Sie damit in seltsame Randfälle geraten ... möglicherweise ist mehr Intelligenz erforderlich, als ein Skript bieten kann. Ich würde klein anfangen und einer Wiederherstellungsfunktion vorsichtig Funktionen hinzufügen.

verwandte Informationen