Linux ssh: Ermöglicht die Authentifizierung mit öffentlichem Schlüssel, ohne dem Benutzer Leserechte für privaten Schlüssel zu gewähren


14

Auf meinem Linux-Server angemeldete Benutzer sollten in der Lage sein, mit einem Standardkonto auf einen bestimmten Remote-Computer zu sshen. Die Authentifizierung auf dem Remotecomputer verwendet den öffentlichen Schlüssel, sodass auf dem Server der entsprechende private Schlüssel verfügbar ist.

Ich möchte nicht, dass die Serverbenutzer den privaten Schlüssel tatsächlich lesen können. Die Tatsache, dass sie Zugriff auf den Server haben, ermöglicht ihnen das SSH-Recht, und das Entfernen von ihnen vom Server sollte auch die Verbindung zum Remotecomputer verhindern.

Wie kann ich Benutzern erlauben, eine SSH-Verbindung zu öffnen, ohne ihnen Lesezugriff auf den privaten Schlüssel zu gewähren?

Meine bisherigen Gedanken: Natürlich muss die ausführbare Datei ssh in der Lage sein, den privaten Schlüssel zu lesen, also muss sie unter einem anderen Benutzer auf dem Server laufen, der diese Rechte hat. Sobald die SSH-Verbindung hergestellt ist, kann ich sie an den Benutzer "weiterleiten", damit er Befehle eingeben und mit dem Remote-Computer interagieren kann.

  • Ist das ein guter Ansatz?
  • Wie soll ich das forward implementieren?
  • Wie kann der Benutzer die Verbindung herstellen (dh die Ausführung von ssh durch den Benutzer, der über Leserechte für den Schlüssel verfügt)?
  • Gibt es eine Sicherheitslücke? - Wenn die Benutzer einen ssh als einen anderen Benutzer ausführen können, können sie dann alles tun, was der andere Benutzer könnte (einschließlich des Lesens des privaten Schlüssels)?


1
Konfigurieren Sie den Remote-Server so, dass Verbindungen mit diesem Schlüssel nur von der IP-Adresse Ihres Servers akzeptiert werden? Auf diese Weise können sie nichts tun, auch wenn sie den Schlüssel stehlen.

@ AndréDaniel na ja, vielleicht könnten sie sich bei einem anderen, völlig unabhängigen Computer anmelden, der auch so konfiguriert ist, dass er passwortlose Anmeldungen vom Server akzeptiert. Das ist der einzige Grund, warum ich mir vorstellen kann, ein solches Setup zu haben. wenn es das nicht ist, bin ich ziemlich neugierig, was es ist. (Nicht, dass es wirklich wichtig ist.)
David Z

@DavidZ Ich verstehe nicht wirklich ... der Schlüssel sollte nirgendwo als vertrauenswürdig eingestuft werden, außer auf dem Zielserver, vorausgesetzt, die IP stimmt mit der des ersten Servers überein (zu dem die Benutzer eine Verbindung herstellen).

2
Wenn Sie es auf diese Weise sperren müssen, haben Sie vermutlich Maßnahmen ergriffen, um zu verhindern, dass Benutzer der ~/.ssh/authorized_keysDatei neue öffentliche Schlüssel hinzufügen .
MPONTILLO

Antworten:


31

Das ist einer der Gründe sudo. Erlauben Sie Ihren Benutzern einfach, einen einzelnen Befehl auszuführen, wobei nur die vorautorisierten Befehlszeilenoptionen verwendet werden und die offensichtlichsten Umgehungen behoben werden. z.B

#/etc/sudoers
%users ALL = (some_uid) NOPASSWD: /usr/bin/ssh -i /home/some_uid/.ssh/remote-host.key username@remotehost

Richtet ein , sudodass alle Mitglieder der Gruppe usersden Befehl ssh als Benutzer some_uid ausführen können, ohne ein eigenes Kennwort (oder das des Kontos some_uid) einzugeben, wenn sie ausgeführt werden:

sudo -u some_uid /usr/bin/ssh -i /home/some_uid/.ssh/remote-host.key username@remotehost

Deaktivieren Sie die NOPASSWD:Option, um zu erzwingen, dass Benutzer ihre eigenen Kennwörter eingeben, bevor Sie sich beim Remote-Host anmelden.
Richten Sie möglicherweise ein Alias- oder Wrapper-Skript ein, um Ihren Benutzern die sudoArbeit zu erleichtern, da die Verwendung der richtigen Argumente äußerst wählerisch ist.


Klappt wunderbar. Dies sollte auch die empfohlene Antwort für das von Wenzul erwähnte Duplikat sein.
Philipp

10

Dies scheint ein guter Anwendungsfall für die hostbasierte Authentifizierung zu sein. Dies ist eine Authentifizierungsmethode, bei der SSH keinen einzelnen Benutzerschlüssel auf dem lokalen Computer (in diesem Fall Ihren Server) zur Authentifizierung verwendet. Stattdessen wird der private Schlüssel des Hosts verwendet , der in gespeichert ist /etc/ssh/und nur von gelesen werden kann root.

Um dies einzurichten, müssen Sie eine Datei mit dem Namen .shostsauf dem Remotecomputer im Ausgangsverzeichnis des Benutzers erstellen , unter dem sich die Benutzer anmelden sollen (nicht anmelden ~/.ssh). Die Datei sollte den Inhalt haben

server-hostname +

Wo server-hostnameist der Name Ihres Servers und +ist ein wörtliches Pluszeichen, das als Platzhalter für "jeden Benutzer" dient.

Sie müssen auch sicherstellen, dass der Remotecomputer den Hostschlüssel des Servers überprüfen kann. Dies bedeutet, dass der Hostschlüssel des Servers entweder auf dem Remotecomputer /etc/ssh/ssh_known_hostsoder ~/.ssh/known_hostsauf diesem aufgeführt sein muss . Wenn dies nicht bereits der Fall ist, können Sie es einrichten, indem Sie sich beim Remote-Computer anmelden und ausführen

ssh-keyscan server-hostname >> /etc/ssh/ssh_known/hosts

Sobald Sie diese Schritte eingerichtet haben, können Sie den privaten Schlüssel auf dem Server vollständig löschen, wenn Sie ihn für nichts anderes benötigen. (Und wenn Sie dies tun, können Sie es immer so einstellen, dass es nur von rootoder von etwas lesbar ist .)

Sie können auch auf einfache Weise bestimmte Benutzer auf den Remotecomputer zugreifen lassen oder ihnen den Zugriff verweigern. Weitere Informationen finden Sie auf den Manpages von sshund hosts.equiv.

Ein Problem bei dieser Konfiguration besteht darin, dass Benutzer, die sich auf dem Remotecomputer anmelden, Änderungen vornehmen können .shosts. Sie können nichts tun, um sich als ein anderer Benutzer bei der Remote-Maschine anzumelden, aber sie könnten den eigenen oder fremden Zugriff auf die Remote-Maschine unterbrechen. Wenn dies ein Problem ist, können Sie möglicherweise .shostsnur beschreibbare Dateien erstellen. rootIch bin mir nicht sicher, ob dies funktioniert, aber Sie können es versuchen und sehen. (Andere Methoden wie die mit sudosind dem gleichen Risiko ausgesetzt, da ein Benutzer immer löschen könnte ~/.ssh/authorized_keys.)


+1; Ich denke, diese Option bietet eine gute Flexibilität für den Fall, dass der Benutzer andere SSH-Funktionen als das Terminal verwenden muss, z. B. Portweiterleitung, sichere Kopie usw. Auch ein alternativer SSH-Client sollte funktionieren. Die sudoOption könnte jedoch für eine abgeschottete Umgebung besser sein ...
mpontillo
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.