Frage Wie kann SSH den Benutzer nur vom lokalen Netzwerk root lassen?


Ich habe Google-Authenticator auf einem CentOS 6.5-Rechner installiert und bestimmte Benutzer so konfiguriert, dass sie OTP bereitstellen.

Während der Bearbeitung /etc/ssh/sshd_config Ich habe eine Richtlinie gesehen "PermitRootLogin"Das ist standardmäßig auskommentiert.

Ich würde gerne setzen "PermitRootLogin no"aber immer noch in der Lage sein, als root nur vom lokalen Netzwerk aus auf die Maschine zuzugreifen.

Ist das möglich?


33
2017-07-17 12:07


Ursprung


Tue das niemals. SSH als Ihre Benutzer, dann verwenden Sie sudo, um Berechtigungen zu erhöhen. Machen Sie dies so, dass es eine Papierspur hinterlässt und Sie wissen, welcher Account kompromittiert wurde. - SnakeDoc
@SnakeDoc: Das ist eine Denkrichtung, aber es ist nicht klar und ich würde das Gegenteil behaupten. Sudo ist eine riesige komplexe Angriffsfläche und nicht etwas, das ich jemals installieren möchte. SSH pubkey auth ist eine viel kleinere Angriffsfläche. Beide können protokolliert werden, aber die Protokollierung ist nicht sehr nützlich, wenn der Benutzer (root) Protokolle bearbeiten oder löschen kann. Dies ist immer der Fall, es sei denn, Sie melden sich bei externem Append-Only-Speicher an. - R..
@R .. Wenn Sie sudoers korrekt eingerichtet haben und das Prinzip der geringsten Berechtigung verwenden, sind diese Probleme, die Sie beschrieben haben, größtenteils kein Problem. Kein Benutzer sollte in der Lage sein, und sudo - su in root oder tun Sie alles, was ihre Benutzer nicht brauchen (in Sudoers verwenden Sie whitelist für Befehle). Wenn Sie root benötigen, müssen Sie physisch an der Konsole sein - dh. Root über SSH sollte niemals erlaubt sein ... Schlüssel oder nicht. - SnakeDoc
@SnakeDoc: Sie irren sich. Sudo hat seine eigenen komplexen Angriffsflächen, und fundamentale komplexe Angriffsfläche, die einem suid binary inhärent ist, in Form des gesamten Zustands, der in execve geerbt wird. In einigen Fällen wird ein Fehler im suid-Programm selbst (suid) nicht einmal benötigt; Fehler in der zugrunde liegenden Infrastruktur wie dem dynamischen Linker (z. B. CVE-2010-3856) können ausreichend sein. - R..
@R .. Sie gehen davon aus, dass Sie immer wissen werden, wenn ein Schlüssel verloren geht. Das ist eine Annahme. Außerdem hat Ihr Angreifer Root-Rechte. Es ist immer noch besser, sie über ein nicht privilegiertes Konto zu senden und sie zu root zu machen. Auf diese Weise haben Sie einen Schlüssel, der durchgesickert sein muss, eine Schlüsselpassphrase, die zu brechen ist, und dann ein normales Benutzerkontokennwort, um zu brechen. Und wenn der Angreifer all das durchmacht ... können sie nichts tun, weil dieser Benutzer unter sudoers mit sehr eingeschränkter Fähigkeit eingerichtet ist ... Sehen Sie den Vorteil jetzt? Erlaube keine direkte root-Anmeldung über ssh ... periode. Es ist eine gute Hygiene - SnakeDoc


Antworten:


Benutze die Match Konfigurationsparameter in /etc/ssh/sshd_config:

# general config
PermitRootLogin no 

# the following overrides the general config when conditions are met. 
Match Address  192.168.0.*
    PermitRootLogin yes

Sehen man sshd_config 


53
2017-07-17 12:47



Warum habe ich nicht daran gedacht? Danke Kumpel - Itai Ganot
Sie können die Quelle für Authentifizierungsschlüssel auch einschränken ~root/.ssh/authorized_keys. Setzen Sie den Schlüssel mit voran from="192.168.0.0/24 ". - BillThor
Ich würde es ändern, um IPv6 link-local Adressen auch zu erlauben. Die Art und Weise, wie verbindungslokale Adressen in IPv6 funktionieren, macht sie sehr robust gegenüber falsch konfigurierten Netzwerken. Das bedeutet, wenn Sie eine falsche Konfiguration des Netzwerks beheben müssen, ist es möglich, dass die Verwendung einer IPv6-Link-lokalen Adresse die einzige verbleibende Option ist. - kasperd


Das Match address Methode wurde bereits erwähnt, aber Sie können auch die Benutzer (oder Gruppen) einschränken, die sich auf einem System anmelden dürfen. Zum Beispiel, um Anmeldungen an den Benutzer zu beschränken itai (von überall) und root (aus einem bestimmten Netzwerk), verwenden Sie:

AllowUsers itai root@192.168.0.*

Dies verhindert alle anderen Benutzer (wie apache) vom Einloggen über SSH.

Siehe auch die AllowUsers Stichwort in der sshd_config (5) Handbuch.


14
2017-07-17 17:51



ich bevorzuge AllowGroups und alle Benutzer hinzufügen, die sich mit SSH in einer bestimmten Gruppe anmelden können. Schätze, es ist eine Frage des Geschmacks, aber das scheint weniger Bearbeitung von sshd_config zu sein (was zu einem geringeren Risiko führt, alle zu verderben und zu sperren). - α CVn
@ MichaelKjörling AllowGroups bedeutet auch, dass Sie keine Bearbeitungsberechtigungen für sshd_config benötigen, wenn Ihr Team erweitert oder verkleinert wird. Dies könnte sogar mehr Führungskräften oder Praktikanten erlauben, dies zu tun. - Nzall
Gute Punkte, beachten Sie, dass Sie Optionen kombinieren können, haben AllowUsers itai root@192.168.0.* und AllowGroups ssh-users und Sie werden nicht versehentlich eine Aussperrung verursachen, falls der Praktikant versehentlich die Gruppe löscht :) - Lekensteyn