Czy istnieje sposób na przekazanie poufnych danych w bash za pomocą monitu dla dowolnego polecenia?

Załóżmy, że użyłem sha1passdo wygenerowania skrótu poufnego hasła w wierszu polecenia. Mogę użyć sha1pass mysecretdo wygenerowania skrótu, mysecretale ma to wadę, która mysecretjest teraz w historii bash. Czy istnieje sposób, aby osiągnąć cel końcowy tego polecenia, unikając ujawniania mysecretzwykłego tekstu, być może za pomocą passwdzachęty w stylu?

Interesuje mnie również uogólniony sposób, aby to zrobić w celu przekazywania wrażliwych danych do dowolnego polecenia. Metoda zmieni się, gdy wrażliwe dane zostaną przekazane jako argument (np. sha1passIn) lub STDIN do jakiegoś polecenia.

Czy istnieje sposób na osiągnięcie tego?

Edycja : To pytanie przyciągnęło wiele uwagi, a poniżej podano kilka dobrych odpowiedzi. Podsumowanie to:

• Zgodnie z odpowiedzią @ Kusalananda idealnie byłoby, gdyby nigdy nie trzeba było podawać narzędzia ani hasła lub hasła jako argumentu wiersza poleceń. Jest to podatne na kilka sposobów opisanych przez niego, i należy użyć lepiej zaprojektowanego narzędzia, które jest w stanie pobierać tajne dane wejściowe na STDIN
• Odpowiedź @ vfbsilva opisuje, jak zapobiegać przechowywaniu rzeczy w historii bash
• Odpowiedź Jonathana opisuje doskonale dobrą metodę osiągnięcia tego celu, o ile program może pobierać swoje tajne dane na STDIN. Jako taki postanowiłem zaakceptować tę odpowiedź. sha1passw moim OP był tylko przykładem, ale dyskusja wykazała, że ​​istnieją lepsze narzędzia, które pobierają dane na STDIN.
• jak zauważa @R .. w swojej odpowiedzi , użycie interpretacji poleceń dla zmiennej nie jest bezpieczne.

Podsumowując, zaakceptowałem odpowiedź @ Jonathana, ponieważ jest to najlepsze rozwiązanie, biorąc pod uwagę, że masz dobrze zaprojektowany i dobrze działający program do pracy. Chociaż przekazanie hasła lub hasła jako argumentu wiersza polecenia jest zasadniczo niebezpieczne, inne odpowiedzi zapewniają sposoby złagodzenia prostych problemów związanych z bezpieczeństwem.

Jeśli używasz powłoki zshlub bash, użyj opcji -s readwbudowanej powłoki, aby odczytać wiersz z urządzenia końcowego bez jego echa.

IFS= read -rs VARIABLE < /dev/tty

Następnie możesz użyć fantazyjnego przekierowania, aby użyć zmiennej jako stdin.

sha1pass <<<"$VARIABLE"

Jeśli ktokolwiek psucieknie, zobaczy tylko „sha1pass”.

Zakłada się, że sha1passczyta hasło ze standardowego wejścia (w jednym wierszu, ignorując ogranicznik wiersza), gdy nie podano żadnego argumentu.

Najlepiej, aby nigdy nie wpisywać hasła jawnego tekstu w wierszu polecenia jako argumentu polecenia. W ten sposób hasło staje się argumentem polecenia, a argumenty wiersza poleceń mogą być widoczne w tabeli procesów za pomocą prostych narzędzi, takich jak psdzienniki kontroli lub zalogowane do nich.

To powiedziawszy, z pewnością istnieją sposoby na ukrycie faktycznego hasła w historii poleceń powłoki.

sha1pass "$( head -n 1 )"

Następnie wpisz hasło i naciśnij Enter. headKomenda używana tutaj przyjąć dokładnie jeden wiersz danych wejściowych i ostatni przełamane, że typ nie będzie część danych, które są przekazywane do sha1pass.

Aby zapobiec powtórzeniu się znaków:

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

Te stty -echozakręty dowodzenia off echo wpisywanych znaków z na terminalu. Echo jest następnie przywracane za pomocą stty echo.

Aby przekazać standardowe wejście, to ostatnie polecenie może zostać zmienione (zrobiłbyś to, gdyby sha1passzaakceptowano dane na standardowym wejściu, ale wygląda na to, że to konkretne narzędzie ignoruje standardowe wejście):

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

Jeśli potrzebujesz wprowadzania wielowierszowego (powyższe założenie, że należy przekazać jedną linię, bez znaku nowej linii na końcu), zastąp całą headkomendę cati zakończ wprowadzanie (zakładając somecommand, że odczytuje do końca pliku) Ctrl+D( śledzenie, Returnjeśli chcesz wstawić znak nowego wiersza, lub dwa razy, jeśli nie).

Działa to niezależnie od używanej powłoki (pod warunkiem, że była to powłoka Bourne'a lub rc).

Niektóre powłoki mogą powodować, że nie zapisują wpisanych poleceń w swoich plikach historii, jeśli polecenie jest poprzedzone spacją. Zazwyczaj wiąże się to z koniecznością ustawienia HISTCONTROLwartości ignorespace. To jest obsługiwane przez co najmniej bashi kshna OpenBSD, ale nie przez np ksh93lub dash. zshużytkownicy mogą użyć histignorespaceopcji lub ich HISTORY_IGNOREzmiennej do zdefiniowania wzorca do zignorowania.

W powłokach obsługujących czytanie readbez echa znaków na terminalu można również użyć

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"

ale to oczywiście ma ten sam problem z potencjalnym ujawnieniem hasła w tabeli procesów.

Jeśli narzędzie odczytuje ze standardowego wejścia, a powłoka obsługuje „ciągi znaków”, powyższe można zmienić na

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

Podsumowanie komentarzy poniżej:

• Wykonanie polecenia z hasłem podanym w wierszu polecenia, co robi wszystkie powyższe polecenia, z wyjątkiem tego, które przekazuje dane do polecenia, potencjalnie sprawi, że hasło będzie widoczne dla każdego, kto działa psw tym samym czasie. Żadne z powyższych poleceń nie zapisze jednak wpisanego hasła w pliku historii powłoki, jeśli zostanie wykonane z interaktywnej powłoki.

• Dobrze zachowujące się programy, które czytają hasła w postaci czystego tekstu, robią to, czytając ze swojego standardowego wejścia, z pliku lub bezpośrednio z terminala.

• sha1pass wymaga hasła w wierszu polecenia, wpisanego bezpośrednio lub przy użyciu zastępowania polecenia.

• Jeśli to możliwe, użyj innego narzędzia.

Jeśli tak ustawisz HISTCONTROL:

HISTCONTROL=ignorespace

i uruchom polecenie spacją:

~$  mycommand

nie będzie przechowywany w historii.

Przekaż wrażliwe dane za pomocą potoku lub tutaj:

command_with_secret_output | command_with_secret_input

lub:

command_with_secret_input <<EOF
$secret
EOF

Sekrety są dobrze w (nieeksportowanych) zmiennych powłoki, ale nigdy nie można używać tych zmiennych w wierszach poleceń, tylko w dokumentach tutaj i wewnętrznych elementach powłoki.

Jak zauważył Kusalananda w komentarzu, jeśli wpisujesz polecenia w interaktywnej powłoce, linie, które wprowadzasz dla dokumentu tutaj, zostaną zapisane w historii powłoki, więc wpisanie hasła nie jest bezpieczne, ale nadal powinno być bezpieczne w użyciu zmienne powłoki zawierające sekrety; historia będzie zawierać tekst, $secreta nie wszystko, co zostało $secretrozszerzone.

Korzystanie z rozszerzeń poleceń nie jest bezpieczne :

command_with_secret_input "$(command_with_secret_output)"

ponieważ dane wyjściowe zostaną dołączone do wiersza poleceń i będą widoczne w psdanych wyjściowych (lub ręcznie czytane z / proc), z wyjątkiem systemów z hartowanym / proc.

Przypisanie do zmiennej jest również w porządku:

secret=$(command_with_secret_output)

Po prostu wpisz wartość do pliku i przekaż plik:

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

Nie jestem pewien, jak to sha1passdziała, jeśli można pobrać plik jako dane wejściowe, możesz użyć sha1pass < mysecret. Jeśli nie, używanie catmoże być problemem, ponieważ zawiera ostatnią nową linię. W takim przypadku użyj (jeśli headobsługuje -c):

head -c-1 mysecret | sha1pass 

Jeśli to, co zrobił terdon, jest możliwe, to jest to najlepsze rozwiązanie, przechodząc przez standardowe dane wejściowe. Pozostał tylko problem, że zapisał hasło na dysk. Zamiast tego możemy to zrobić:

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

Jak powiedział Kusalananda, stty -echozapewnia , że to, co piszesz, nie będzie widoczne, dopóki nie stty echopowtórzysz. head -1otrzyma jeden wiersz ze standardowego wejścia i przekaże go do sha1pass.

użyłbym

sha1pass "$(cat)"

catbędzie czytać ze standardowego do EOF, co może być spowodowane naciśnięciem Ctrl + D. Następnie wynik zostanie przekazany jako argument dosha1pass