Frage Ist eine zentrale Stelle für authorized_keys eine gute Idee?


Ich bin dabei, einen Cloud-Server so zu konfigurieren, dass der folgende Stapel ausgeführt wird: Ruby, Passenger, Apache; unter Ubuntu 10.04 (Lucid Lynx).

Um den Server einfacher zu verwalten, richte ich RSA-Schlüssel ein root, und www-data damit ich kann ssh in den Server. Was ich nicht mochte, war das www-dataist es .ssh Verzeichnis saß in /var/www Das ist das Standardverzeichnis für Apache. Meine Sorge ist, dass, wenn Apache nicht richtig konfiguriert ist, die .ssh Verzeichnis kann offen gelegt werden.

Ich bin auf die Lösung gestoßen, um die ~/.ssh/authorized_keys Datei an einem zentralen Ort durch Ändern AuthorizedKeysFile im /etc/ssh/sshd_config. Dies kommt mit 2 Profis: Ein einziger Ort für Schlüssel, und keine Sorgen über eine schlechte Apache-Konfiguration. Der einzige Trick, den ich mir vorstellen kann ist, dass jetzt jeder Benutzer für die Anmeldung auf dem Server zur Verfügung steht (eindeutig ein zweischneidiges Schwert der zentralen Schlüsseldatei).

Gibt es etwas, das ich in dieser Konfiguration vermisst habe? Habe ich mich selbst entblößt, oder ist das eine bessere Lösung als Individuum? authorized_keys Dateien?

Ich bin Grün wenn es um Server-Management geht, aber ich bin total bereit, schlechte Namen für schlechte Dinge zu nennen. : D


26
2017-09-20 15:05


Ursprung


Zumindest öffentliche Schlüssel, die im Internet (schreibgeschützt) verfügbar gemacht werden, sind nicht das größte Risiko ... (Es könnte Angreifern erlauben, zu sehen, ob sie sich mit einem privaten Schlüssel, den sie woanders erhalten haben, in den Server einloggen können erlauben Sie ihnen nicht, sich einzuloggen, indem Sie nur das bekommen ...) (Die ernsthaften Probleme sind, wenn es ein id_rsa Datei in ~/.ssh und sie schaffen es, das zu lesen) - Gert van den Berg


Antworten:


Alle Keys-Dateien können im selben Verzeichnis zentralisiert und nicht in derselben Datei gemischt werden.

Einfach einrichten sshd_config Datei so:

AuthorizedKeysFile  /etc/ssh/authorized_keys/%u

Auf deinem Server:

  • www-Datenschlüssel werden in sein /etc/ssh/authorized_keys/www-data 
  • Root-Schlüssel werden in sein /etc/ssh/authorized_keys/root

Bezüglich der Zugriffsrechte werden diese Einstellungen von sshd akzeptiert:

/etc/ssh/authorized_keys gehört root:root und hat Modus 755. Schlüsseldateien sind Eigentum von root:root und habe den Modus 644.

Andere Modi können funktionieren, aber ich habe sie nicht getestet.


48
2017-09-05 18:05



+1, aber ich würde die anderen nicht setzen. Legen Sie den Besitz der% u-Dateien für den Benutzer fest, damit dies nicht erforderlich ist. - Aaron Copley
Gute Lösung für das Problem, dass böswillige Benutzer mehr öffentliche Schlüssel zu ihren ~ / .ssh / authorized_keys hinzufügen können, die anderen Zugriff gewähren. - bbaassssiiee
Ich habe gerade bestätigt, dass der Modus 600 für die autorisierte Schlüsseldatei eines Benutzers nicht funktioniert. es muss Modus 644 sein - Luis E.


Im Allgemeinen würde ich nicht tun, was Sie vorschlagen. Es bricht allgemeine Annahmen (wie ~/.ssh/authorized_keys arbeitet für Ihre Benutzer und führt Probleme ein, die Sie bereits in Ihrer Frage erwähnt haben. Wenn Sie vor der Implementierung eklatante Probleme feststellen, bedeutet dies, dass Ihre Lösung nicht ideal ist.

Sicherheitsmäßig denke ich auch, dass es ein FURCHTBAR Idee, dass jeder ein Service-Konto teilt: Im Moment sind nur Sie und Sie wissen, dass Sie derjenige sind, der Änderungen vornimmt. In 5 Jahren, wenn du 5 Admins hast, wirst du wissen wollen, wer was geändert hat, und durch Auditing-Logs graben, um zu sehen, wer welchen Schlüssel benutzt hat, wenn es ein königlicher Schmerz ist.
Sie sind besser dran, wenn sich Leute einloggen und benutzen sudo oder etwas Ähnliches, um ihre Privilegien zu erweitern und alles zu tun, was sie tun müssen.


Wenn Sie weiterhin SSH-Schlüssel zentralisieren möchten, schlage ich vor, in ein Bereitstellungssystem zu schauen Marionette oder Radgeist verwalten / verteilen authorized_keys Dateien zu den entsprechenden ~user/.ssh/ Verzeichnisse (oder hacken eine selbstgewachsene Lösung, die SCPs an Ort und Stelle).
Wenn Sie zu mehreren Servern expandieren, möchten Sie vielleicht nachsehen der LDAP Public Key-Patch für ältere Versionen von OpenSSH (oder die AuthorizedKeysCommandRichtlinie und ein entsprechendes Skript in der neueren Version von OpenSSH), damit Sie Ihre Benutzer zentralisieren können und ihre Schlüssel nicht über Ihr gesamtes Netzwerk verteilen müssen, aber das ist wahrscheinlich ziemlich weit für Sie.


15
2017-09-20 15:41



+1 für das Sharing-Argument. Kurz gesagt, weil ich einen Moment brauchte, um die Implikation zu erkennen: Es sollte überhaupt kein ~ www-data / .ssh Verzeichnis geben, also kein Sicherheitsrisiko durch den Webbrowser. - thiton
Danke für die Rückmeldung! Wenn ich dich richtig verstehe. Ich sollte keines haben root Noch www-data Zugänglich über einen SSH-Schlüssel ist das korrekt? - Gavin Miller
Ein ... haben ~www-data/.ssh Verzeichnis ist keine schreckliche Sache (mit entsprechenden Berechtigungen ist es kein wesentliches Risiko), aber wenn Sie verwenden werden ~www-data/.ssh Es ist wahrscheinlich besser, deine Webroot nicht zu haben ~www-data (entweder den Webroot bewegen oder bewegen www-dataHeimatverzeichnis). Die Differenzierung der Benutzer ist das größere Argument IMHO - ich weiß, wenn ich sehe jsmith Einloggen Ich weiß, es ist John Smith. Wenn ich sehe www-data Einloggen Ich muss mehr graben, um herauszufinden wer das war. - voretaq7
Der Grund, warum ich einen SSH-Schlüssel für www-Daten benötigte, ist, dass ich Beanstalk (SCM & Deploy-Tool) verwende, um die Bereitstellungen über SFTP durchzuführen. Soll ich dann einen separaten Account für Beanstalk erstellen, um das FTP zu tun? Was wäre dort die beste Lösung? - Gavin Miller
@Gavin - Ich persönlich glaube nicht, dass sich jemals jemand bei Dienstkonten einloggen sollte, und root sollte niemals über das Netzwerk zugänglich sein (nur Konsolenanmeldung). Sie sollten natürlich Bestimmungen haben, um in Ihr System zu gelangen und root zu werden. Ich habe jedoch ein sehr hohes Maß an Paranoia. Wenn Sie ein Tool (wie Beanstalk) haben, das Zugriff benötigt, kann dies aus Gründen der Einfachheit eine Ausnahme rechtfertigen, aber hüten Sie sich vor dem "Wer hat was wann gemacht?" Verwirrung, die entstehen kann, wenn das Werkzeug nicht robust ist ... - voretaq7