Gibt es eine Möglichkeit, vertrauliche Daten in bash mit einer Eingabeaufforderung für einen Befehl weiterzuleiten?

Angenommen, ich habe sha1passeinen Hash eines vertraulichen Kennworts in der Befehlszeile generiert. Ich kann verwenden sha1pass mysecret, um einen Hash zu generieren, mysecretaber das hat den Nachteil, dass mysecretes jetzt in der Bash-Geschichte ist. Gibt es eine Möglichkeit, das Endziel dieses Befehls zu erreichen, ohne dass dies mysecretim Klartext passwdangezeigt wird, z. B. mithilfe einer Eingabeaufforderung im -Stil?

Ich bin auch an einer verallgemeinerten Methode interessiert, um vertrauliche Daten an einen Befehl weiterzuleiten. Die Methode würde sich ändern, wenn die vertraulichen Daten als Argument (z. B. in sha1pass) oder in STDIN an einen Befehl übergeben werden.

Gibt es eine Möglichkeit, dies zu erreichen?

Bearbeiten : Diese Frage hat viel Aufmerksamkeit erregt und es wurden einige gute Antworten unten angeboten. Eine Zusammenfassung ist:

• Wie pro @ Kusalananda Antwort , im Idealfall würde man nie ein Passwort oder Geheim als Befehlszeilenargument zu einem Dienstprogramm geben muß. Dies ist in mehrfacher Hinsicht verwundbar, wie von ihm beschrieben, und man sollte ein besser gestaltetes Dienstprogramm verwenden, das in der Lage ist, die geheimen Eingaben auf STDIN zu übernehmen
• @ vfbsilvas Antwort beschreibt, wie Sie verhindern, dass Dinge im Bash-Verlauf gespeichert werden
• @ Jonathans Antwort beschreibt eine vollkommen gute Methode, um dies zu erreichen, solange das Programm seine geheimen Daten auf STDIN übertragen kann. Aus diesem Grund habe ich mich entschlossen, diese Antwort zu akzeptieren. sha1passIn meinem OP war dies nur ein Beispiel, aber die Diskussion hat ergeben, dass es bessere Tools gibt, die Daten zu STDIN aufnehmen.
• Wie @R .. in seiner Antwort feststellt , ist die Verwendung der Befehlserweiterung für eine Variable nicht sicher.

Zusammenfassend habe ich @ Jonathans Antwort akzeptiert , da es die beste Lösung ist, vorausgesetzt, Sie haben ein gut gestaltetes und ansprechendes Programm, mit dem Sie arbeiten können. Die Übergabe eines Kennworts oder eines Geheimnisses als Befehlszeilenargument ist zwar grundsätzlich unsicher, die anderen Antworten bieten jedoch Möglichkeiten, um die einfachen Sicherheitsbedenken abzumildern.

Wenn Sie die Shell zshoder verwenden bash, verwenden Sie die Option -s für die integrierte readShell, um eine Zeile vom Endgerät zu lesen, ohne dass sie wiederholt wird.

IFS= read -rs VARIABLE < /dev/tty

Dann können Sie eine ausgefallene Umleitung verwenden, um die Variable als stdin zu verwenden.

sha1pass <<<"$VARIABLE"

Wenn jemand rennt ps, wird er nur "sha1pass" sehen.

Dies setzt voraus, dass sha1passdas Kennwort von stdin gelesen wird (in einer Zeile, wobei das Zeilentrennzeichen ignoriert wird), wenn kein Argument angegeben wird.

Im Idealfall geben Sie niemals ein Klartextkennwort in der Befehlszeile als Argument für einen Befehl ein. Dadurch wird das Kennwort zu einem Argument für den Befehl, und Befehlszeilenargumente können in der Prozesstabelle angezeigt werden, indem einfache Tools verwendet werden, psdie in einigen Überwachungsprotokollen verwendet werden.

Allerdings gibt es durchaus Möglichkeiten, das eigentliche Passwort aus dem Befehlsverlauf der Shell zu entfernen.

sha1pass "$( head -n 1 )"

Geben Sie dann das Passwort ein und drücken Sie Enter. Der headhier verwendete Befehl akzeptiert genau eine Eingabezeile, und die letzte eingegebene neue Zeile ist nicht Teil der Daten, an die übergeben wird sha1pass.

So verhindern Sie das Echo der Zeichen:

sha1pass "$( stty -echo; head -n 1; stty echo )"

Der stty -echoBefehl deaktiviert das Echo der eingegebenen Zeichen auf dem Terminal. Das Echo wird dann mit wiederhergestellt stty echo.

Um die Standardeingabe weiterzugeben, könnte der letzte Befehl geändert werden (dies wäre geschehen, wenn sha1passDaten für die Standardeingabe akzeptiert worden wären , es scheint jedoch, als würde dieses Dienstprogramm die Standardeingabe ignorieren):

{ stty -echo; head -n 1; stty echo; } | somecommand

Wenn Sie eine mehrzeilige Eingabe benötigen (in den obigen Abschnitten wird davon ausgegangen, dass eine einzelne Zeile ohne Zeilenumbruchzeichen am Ende übergeben werden soll), ersetzen Sie den gesamten headBefehl durch catund beenden Sie die Eingabe (vorausgesetzt somecommand, sie liest sich bis zum Ende der Datei) mit Ctrl+D( folgenden, Returnwenn Sie ein Zeilenumbruchzeichen in die Eingabe aufnehmen möchten, oder zweimal, wenn nicht).

Dies funktioniert unabhängig davon, welche Shell Sie verwenden (sofern es sich um eine Bourne-ähnliche oder eine RC-ähnliche Shell handelt).

Bei einigen Shells kann es vorkommen, dass die eingegebenen Befehle nicht in ihren Verlaufsdateien gespeichert werden, wenn vor dem Befehl ein Leerzeichen steht. In der Regel muss hierfür HISTCONTROLder Wert eingestellt werden ignorespace. Dies wird von mindestens bashund kshunter OpenBSD unterstützt, aber nicht von zB ksh93oder dash. zshBenutzer können die histignorespaceOption oder ihre HISTORY_IGNOREVariable verwenden, um ein zu ignorierendes Muster zu definieren.

In Shells, die das Lesen mit unterstützen, readohne Zeichen an das Terminal zu senden, können Sie auch verwenden

IFS= read -rs password     # -s turns off echoing in bash or zsh
                           # -r for reading backslashes as-is,
                           # IFS= to preserve leading and trailing blanks
sha1pass "$password"

Dies hat jedoch offensichtlich immer noch das gleiche Problem mit der potenziellen Offenlegung des Kennworts in der Prozesstabelle.

Wenn das Dienstprogramm von der Standardeingabe liest und die Shell "here-strings" unterstützt, kann das oben Gesagte in geändert werden

IFS= read -rs password
somecommand <<<"$password"

Zusammenfassung der Kommentare unten:

• Wenn Sie einen Befehl mit einem in der Befehlszeile angegebenen Kennwort ausführen, was bei allen oben genannten Befehlen mit Ausnahme des Befehls, der die Daten an den Befehl weiterleitet, der Fall ist, wird das Kennwort möglicherweise für alle Benutzer sichtbar, psdie gleichzeitig ausgeführt werden. Keiner der obigen Befehle speichert jedoch das eingegebene Kennwort in der Verlaufsdatei der Shell, wenn es von einer interaktiven Shell ausgeführt wird.

• Gut erzogene Programme, die Klartext-Passwörter lesen, lesen dies von ihrer Standardeingabe, aus einer Datei oder direkt vom Terminal.

• sha1pass Dies erfordert das Kennwort in der Befehlszeile, das entweder direkt eingegeben oder durch eine Form der Befehlsersetzung ersetzt wird.

• Verwenden Sie nach Möglichkeit ein anderes Werkzeug.

Wenn Sie so einstellen HISTCONTROL:

HISTCONTROL=ignorespace

und starte den Befehl mit einem Leerzeichen:

~$  mycommand

es wird nicht im Verlauf gespeichert.

Übergeben Sie sensible Daten über eine Pipe oder Here-Doc:

command_with_secret_output | command_with_secret_input

oder:

command_with_secret_input <<EOF
$secret
EOF

Es ist in Ordnung, dass sich Geheimnisse in (nicht exportierten) Shell-Variablen befinden, aber Sie können diese Variablen niemals in Befehlszeilen verwenden, nur in Here-Dokumenten und Shell-Interna.

Wie Kusalananda in einem Kommentar angemerkt hat, werden die Zeilen, die Sie für ein Here-Dokument eingeben, im Shell-Verlauf gespeichert, wenn Sie Befehle in eine interaktive Shell eingeben. Es ist also nicht sicher, dort ein Kennwort einzugeben, es sollte jedoch immer noch so sein sichere Verwendung von Shell-Variablen, die Geheimnisse enthalten; Der Verlauf enthält den Text $secretund nicht das, worauf er $secreterweitert wurde.

Die Verwendung von Befehlserweiterungen ist nicht sicher :

command_with_secret_input "$(command_with_secret_output)"

da die Ausgabe in der Befehlszeile enthalten und in der psAusgabe sichtbar ist (oder manuell aus / proc liest), außer auf Systemen mit gehärtetem / proc.

Die Zuweisung zu einer Variablen ist auch in Ordnung:

secret=$(command_with_secret_output)

Schreiben Sie einfach den Wert in eine Datei und übergeben Sie die Datei:

$ cat > mysecret
Big seecreeeet!
$ cat mysecret | sha1pass 

Ich bin mir nicht sicher, wie es sha1passfunktioniert, wenn es eine Datei als Eingabe nehmen kann, die Sie verwenden können sha1pass < mysecret. Wenn nicht, ist die Verwendung catmöglicherweise ein Problem, da sie die letzte Zeile enthält. Wenn dies der Fall ist, verwenden Sie (wenn Ihre headUnterstützung -c):

head -c-1 mysecret | sha1pass 

Wenn das, was terdon getan hat, möglich ist, dann ist das die beste Lösung, indem es die Standardeingabe durchläuft. Das einzige Problem ist, dass er das Passwort auf die Festplatte geschrieben hat. Wir können dies stattdessen tun:

stty -echo
echo -n "password: "
head -1 | sha1pass
stty echo

Wie Kusalananda sagte, stty -echostellt sicher, dass das, was Sie eingeben, erst stty echowieder angezeigt wird, wenn Sie es erneut tun . head -1erhält eine Zeile von der Standardeingabe und leitet sie an weiter sha1pass.

ich würde ... benutzen

sha1pass "$(cat)"

catwürde von stdin bis lesen EOF, was durch Drücken von Strg + D verursacht werden kann. Dann würde das Ergebnis als Argument an übergebensha1pass