gpg szyfruje plik bez interakcji z klawiaturą [zamknięte]

Wykonuję następne polecenie w tabeli crontab, aby zaszyfrować plik i nie chcę interakcji z klawiaturą

echo "PASSPHRASE" | gpg --passphrase-fd 0 -r USER --encrypt FILENAME.TXT

ale mam taką odpowiedź:

gpg: C042XXXX: There is no assurance this key belongs to the named user

pub  40XXX/C042XXXX 2012-01-11 Name LastName. (comment) <[email protected]>
 Primary key fingerprint: XXXX XXXX XXXX XXXX XXXX  XXXX XXXX XXXX XXXX XXXX
      Subkey fingerprint: XXXX XXXX XXXX XXXX XXXX  XXXX XXXX XXXX XXXX XXXX

It is NOT certain that the key belongs to the person named
in the user ID.  If you *really* know what you are doing,
you may answer the next question with yes.

Use this key anyway? (y/N) 

Jak dał do zrozumienia David, problem polega na tym, że gpg nie ufa kluczowi publicznemu, którego używasz do szyfrowania. Możesz podpisać klucz, jak wyjaśnił.

Alternatywą - zwłaszcza jeśli klucz może się od czasu do czasu zmieniać - byłoby przypięcie --trust-model always do polecenia gpg.

Oto odpowiedni fragment ze strony podręcznika:

--trust-model pgp|classic|direct|always|auto

     Set what trust model GnuPG should follow. The models are:

     pgp    This is the Web of Trust combined with trust signatures as used in
            PGP 5.x and later. This is the default trust model when creating a
            new trust database.

     classic
            This is the standard Web of Trust as used in PGP 2.x and earlier.

     direct Key validity is set directly by the user and  not  calculated  via
            the Web of Trust.

     always Skip  key  validation  and  assume that used keys are always fully
            trusted. You generally won't use this unless you  are  using  some
            external  validation  scheme.  This  option  also  suppresses  the
            "[uncertain]" tag printed with signature checks when there  is  no
            evidence that the user ID is bound to the key.

     auto   Select  the  trust  model depending on whatever the internal trust
            database says. This is  the  default  model  if  such  a  database
            already exists.

Oto moje rozwiązanie oparte na gpg2 (ale założę się, że możesz zastosować podobną technikę do gpg)

$ gpg2 --edit-key {recipient email address}  
> trust
> 5 (select 5 if you ultimately trust the key) 
> save

To powie gpg2, aby w pełni zaufać kluczowi, abyś mógł szyfrować bez pytania

Podejście hakerskie:

echo -n PASSPHRASE > phrase
chmod 400 phrase #Make sure ONLY the user running the cron job can read the phrase
yes | gpg --passphrase-fd 3 --recipient USER --encrypt FILENAME.txt 3<phrase

Podstawowy problem polega na tym, że klucz, który masz dla USER, nie jest podpisany. Jeśli jej ufasz, możesz to podpisać

gpg --edit-key USER sign

Prawdopodobnie zada kilka pytań, w zależności od twojej konfiguracji. Zrób to raz, wtedy powinieneś być dobry w swoim crontabie. Nadal zalecałbym skorzystanie z rozwiązania, które zaproponowałem, umieszczając hasło w osobnym pliku i umożliwiając odczytanie go tylko przez jednego użytkownika, którego polecenie działa jako. Jeśli to zrobisz, możesz zabić yes |i po prostu mieć linię szyfrowania.

Użyj tego polecenia, to ci pomoże

echo "PASSPHRASE" | gpg --passphrase-fd 0 --always-trust -r USER --encrypt FILENAME.TX

Ja też w to wpadałem. Nie mogłem zdobyć klucza do podpisu, żeby zrobić coś interesującego. Oto co zrobiłem:

utwórz klucz gpg:

gpg --gen-key

pobierz długi identyfikator klucza (wynik znajduje się w piątej kolumnie):

gpg --list-keys --with-colon [email protected]

Dodaj linię zaufanego klucza do ~ / gnupg / gpg.conf

trusted-key 16DIGITALPHANUMERICKEYID

gpg w skrypcie kopii zapasowej:

gpg -e -r [email protected] backup_file.tgz

Debugowanie crona: przechwytuję również dane wyjściowe dubugowania cron, wysyłając stdout i stderr do pliku dziennika w wierszu poleceń cron. Warto wiedzieć

Zakładam, że podobnie jak ja, wiele osób przychodzi tutaj po część pytania „bez interakcji z klawiaturą”. W przypadku gpg2 i gpg-agent podpisywanie / szyfrowanie / odszyfrowywanie rzeczy bez interakcji z klawiaturą było dość skomplikowane. Oto, jak utworzyć podpis, gdy hasło klucza prywatnego w postaci zwykłego tekstu jest zapisywane w pliku tekstowym:

cat something_so_sign.xzy | gpg \
    --passphrase-file "plaintext_passphrase.txt" \
    --batch \
    --pinentry-mode loopback \
    -bsa

Zmień -b -s -a w zależności od potrzeb. Pozostałe przełączniki są obowiązkowe. Możesz także po prostu użyć --passphrase 'SECRET'. Jak już wspomniano, bądź z tym ostrożny. Oczywiście pliki tekstowe w postaci zwykłego tekstu nie są dużo lepsze.

Lub podpisz klucz (oczywiście po zweryfikowaniu odcisku palca):

gpg --sign-key <recipient email address>

Następnie w pełni ufasz kluczowi.

  1 = I don't know or won't say
  2 = I do NOT trust
  3 = I trust marginally
  4 = I trust fully
  5 = I trust ultimately

Kiedy tworzysz certyfikat po raz pierwszy ze swoim identyfikatorem e-mail, wybierz w pełni zaufany certyfikat, a następnie za każdym razem, gdy zaszyfrujesz jakikolwiek plik, nie zadajesz pytania typu .... po więcej informacji otwórz obrazek w powyższym linku.

NIE jest pewne, że klucz należy do osoby wymienionej w identyfikatorze użytkownika. Jeśli ty naprawdę wiesz, co robisz, możesz odpowiedzieć twierdząco na następne pytanie.

Czy mimo to użyć tego klucza? (t / N)

Inne podejście: aby odmówić dostępu do poufnych danych (zamiast zaszyfrować je za pomocą kluczy innych firm), przesyłam TYLKO * mój ** klucz PUBLICZNY na serwer, na którym chcę chronić dane, i używam tego klucza do szyfrowania. Eliminuje to potrzebę interaktywnego monitu o podanie hasła ułatwiającego automatyzację, a co najważniejsze, klucz PRYWATNY znajduje się poza serwerem publicznym.

gpg --batch --yes --trust-model always -r $YOURPUBKEYEMAILADDRESS -e ./file.txt

Jednak jeśli NIE szyfrujesz własnym kluczem publicznym, użycie przełącznika --trust-model alwaysjest nieco ryzykowne. Zresztą inny sposób rozwiązania problemu odmowy dostępu do danych. HTH - Terrence Houlahan