Wir haben ein paar Cluster, die auf AWS laufen (HAProxy/Solr, PGPool/PostgreSQL) und wir haben Skripte eingerichtet, die es ermöglichen, neue Slave-Instanzen automatisch in die Cluster aufzunehmen, indem ihre IPs auf Konfigurationsdateien aktualisiert werden, die auf S3 gespeichert sind. Anschließend wird eine SSH-Verbindung zur Master-Instanz hergestellt, um sie zum Herunterladen der überarbeiteten Konfiguration und Neustarten des Dienstes zu veranlassen. Es funktioniert alles gut, aber beim Testen verwenden wir unser Master-PEM für SSH, was bedeutet, dass es auf einer Instanz gespeichert werden muss. Nicht gut.
Ich möchte einen Nicht-Root-Benutzer, der ein AWS-Schlüsselpaar verwenden kann und Sudo-Zugriff zum Ausführen der Download-Config-and-Restart-Skripte hat, aber sonst nichts. rbash scheint die Lösung zu sein, aber ich verstehe, dass dies unsicher sein kann, wenn es nicht richtig eingerichtet ist.
Welche Sicherheitslücken weist dieser Ansatz auf:
- Neues AWS-Schlüsselpaar für user.pem erstellt (nicht wirklich „Benutzer“ genannt)
- Neuer Benutzer auf Instanzen: Benutzer
- Der öffentliche Schlüssel für den Benutzer befindet sich in ~user/.ssh/authorized_keys (erhalten durch Erstellen einer neuen Instanz mit user.pem und Kopieren aus /root/.ssh/authorized_keys)
- Der private Schlüssel für den Benutzer befindet sich in ~user/.ssh/user.pem
- „Benutzer“ hat die Login-Shell /home/user/bin/rbash
- ~user/bin/ enthält symbolische Links zu /bin/rbash und /usr/bin/sudo
- /etc/sudoers hat den Eintrag „user ALL=(root) NOPASSWD: [Pfad zu Skripten]
- ~user/.bashrc setzt PATH nur auf /home/user/bin/
- ~user/.inputrc hat „Deaktivierungsvervollständigung aktiviert“, um doppeltes Tabulieren von „sudo /“ zum Suchen von Pfaden zu verhindern.
- ~user/ -R gehört root mit schreibgeschütztem Zugriff auf den Benutzer, mit Ausnahme von ~user/.ssh, das Schreibzugriff auf den Benutzer hat (zum Schreiben bekannter Hosts), und ~user/bin/*, das +x ist.
- Die Kommunikation zwischen Instanzen verwendet „ssh -o StrictHostKeyChecking=no -i ~user/.ssh/user.pem user@[host] sudo [scriptname]“
Alle Gedanken sind willkommen.
Markieren...
Antwort1
Ok, keine Antworten, die besagen, dass dies in irgendeiner Weise schrecklich offengelegt wird, außer der Tatsache, dass jemand, der sich in die Benutzeranmeldung einloggt, den PEM-Schlüssel des Benutzers erhält. Damit sollte er nirgendwo anders hinkommen*.
Es funktioniert mit dem oben beschriebenen Ansatz.
*Es gelten die üblichen Vorbehalte