Gibt es eine sichere Möglichkeit, Passwörter zu speichern, die von einem Skript für ssh verwendet werden?

Daher sollte ich zuerst die Schlüsselauthentifizierung mit SSH verwenden. Das muss ich nicht erklären.

Das Problem hierbei ist, dass ich eine (große) Anzahl von Servern habe und ein Skript benötigen muss, um jede dieser zu verbinden.

Ich verwende eine Schlüsselauthentifizierung, wann immer ich kann, sie ist jedoch nicht auf jedem Server möglich (ich habe keine Kontrolle darüber). Also SSH mit Login oder manchmal Telnet.

Für einige habe ich die Passwörter einfach in einer Datenbank gespeichert und mein Skript nimmt sie, wenn nötig. Das Problem ist, dass es nicht wirklich sicher aussieht, es so zu machen. Gibt es eine Möglichkeit, es ein wenig sicherer zu machen?

Wie eine bestimmte Art, es zu speichern?

Wenn Ihr Skript eine Verbindung zu einem dieser Server herstellen kann, kann jeder mit Zugriff auf das Skript (oder mit privilegiertem Zugriff auf den Computer, auf dem das Skript ausgeführt wird) eine Verbindung zu einem dieser Server herstellen.

Wenn das Skript autonom ausgeführt werden muss, sind alle Wetten deaktiviert. Die Antwort hier ist nein, es gibt keine absolut sichere Möglichkeit, Kennwörter in einer solchen Umgebung zu speichern . Es gibt keine absolut sichere und praktische Möglichkeit, etwas zu tun.

Anstatt zu versuchen, das Unvermeidliche zu vermeiden, sollten Sie sich auf die Verteidigung konzentrieren .

Natürlich sollten Sie die Passwörter rechtzeitig angemessen schützen . Dies bedeutet normalerweise, dass Sie sie in einer Datei getrennt von Ihrem Skript aufbewahren und restriktive Dateisystemberechtigungen konfigurieren müssen . Das ist ungefähr alles, was Sie in dieser Hinsicht tun können.

Andere Maßnahmen können dem Prozess mit Sicherheit Unklarheit verleihen . Durch die Verschlüsselung der Passwörter muss der Angreifer nach dem Entschlüsselungsschlüssel suchen. Durch die Verwendung eines durch ein Betriebssystem geschützten Speichers wird im Allgemeinen verhindert, dass andere Benutzer auf Ihren Schlüssel zugreifen (daher bietet dieser Speicher keinen Vorteil gegenüber Dateisystemberechtigungen, außer dass er komplex anzugreifen und zu verwenden ist). Diese Maßnahmen verzögern einen Angriff, verhindern ihn aber keinesfalls gegen einen entschlossenen Angreifer.

Lassen Sie uns nun die Passwörter für einen Moment als öffentlich behandeln . Was können Sie tun, um Schäden zu mindern?

Eine alte und getestete Lösung besteht darin, die Berechtigungsnachweise einzuschränken. Auf einem UNIX-System empfiehlt es sich, einen separaten Benutzer für Ihr Skript einzurichten und die Funktionen dieses Benutzers sowohl auf dem zugreifenden als auch auf dem zugreifenden Server einzuschränken. Sie können die Benutzerfunktionen auf der SSH-Ebene , auf der Shell-Ebene oder möglicherweise mithilfe eines obligatorischen Zugriffskontrollmechanismus wie SELinux einschränken .

Möglicherweise möchten Sie auch die Skriptlogik auf die Server verschieben . Auf diese Weise erhalten Sie eine kleinere Oberfläche, die einfacher zu steuern ist und insbesondere ...

Überwachen . Überwachen Sie immer den Zugriff auf die Server. Protokollauthentifizierung und Befehle werden vorzugsweise in einem Protokoll zum Anhängen ausgeführt . Vergessen Sie nicht, die Änderungen der Skriptdatei auditdbeispielsweise mit zu überwachen .

Natürlich sind viele dieser Mechanismen nicht nützlich, wenn Sie keine Kontrolle über die Server haben, wie Ihre Frage zu implizieren scheint. In diesem Fall empfehle ich Ihnen, Kontakt mit den Administratoren der Server aufzunehmen und diese über Ihr Skript und die möglichen Sicherheitsrisiken zu informieren.

Die kurze Antwort lautet: Nein.

Die lange Antwort lautet: Nein, es gibt keinen völlig sicheren Weg. (Dies schließt Umgebungsvariablen ein, auf die andere Benutzer auf dem Server zugreifen können.) Am ehesten können Sie sie in einem verschlüsselten Format speichern - keepass, eine GPG-verschlüsselte Datei oder ähnliches. Aber irgendwann müssen Sie das Kennwort entschlüsseln, damit Ihr Skript es verwenden kann, und an diesem Punkt sind Sie anfällig.

Mit anderen Worten, Sie müssen sich eingehend mit der Sicherheit befassen, sowohl auf dem Server, auf dem das Skript ausgeführt wird, im Netzwerk als auch auf den Zielservern.

Sie können die Kennwörter in Ihrer Datenbank mit einem zweiten Kennwort verschlüsseln und dieses Kennwort auf einem separaten (dritten) Computer speichern und ein System einrichten, bei dem das Skript, das Kennwörter aus der Datenbank benötigt, diesen dritten Computer verbindet, um das Entschlüsselungskennwort zu erhalten , entschlüsselt das Passwort in der Datenbank mit dem Passwort, das es vom 3. Computer erhalten hat und macht seine Arbeit.

Dies erhöht natürlich nicht wirklich die Sicherheit, ein Angreifer mit ausreichenden Rechten könnte auch nur das Passwort vom 3. Rechner anfordern.

Der Punkt ist jedoch, dass ein Dritter die dritte Maschine kontrollieren könnte, z. B. Ihr Chef oder Sicherheitsbeauftragter, oder der Dritte, der die Kontrolle über die Server hat, die Sie nicht kontrollieren.

Auf diese Weise können Sie ihnen mitteilen, ob sie jemals ein Problem haben, ob Sie Ihren Job gekündigt haben und ob sie dem Mann, der Sie ersetzt, nicht vertrauen oder ob Ihre Skripte nicht mehr auf ihre Maschinen zugreifen sollen. Sie können den Stecker am dritten ziehen Maschine, und Ihre Skripte haben keinen Zugriff mehr auf die Passwörter.