キーボード操作なしのgpg暗号化ファイル[クローズ]


84

ファイルを暗号化するためにcrontab内で次のコマンドを実行していますが、キーボード操作が必要ありません

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

しかし、私はこの答えを持っています:

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

pub  40XXX/C042XXXX 2012-01-11 Name LastName. (comment) <user@email.com>
 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) 

--passphrase-fdは最初の行のみを読み取るため、実行するとどうなりますecho -e "PASSPHRASE" "\nyes" | gpg --passphrase-fd 0 -r USER --encrypt FILENAME.TXTか?
デビッドコスタ

マニュアルページは誰ですか?--batchおよび--yes
u0b34a0f6ae 2013

回答:


76

Davidが示唆したように、ここでの問題は、gpgが暗号化に使用している公開鍵を信頼していないことです。彼が説明したようにあなたは鍵に署名することができます。

別の方法(特にキーが時々変更される可能性がある場合)は--trust-model always、gpgコマンドに取り組むことです。

マニュアルページの関連ビットは次のとおりです。

--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.

システムがそれをコードと見なす理由がわかりません。見積もりをクリックしました。コードではありません。編集すると、引用されたものとしてのみ表示されます(色なし)。奇妙な。
rsaw 2012

4
これは、テキストがスペースを使用して整列しているためです。
トマーシュFejfar

これは私にとって正しい答えです!ありがとう
eigenfield 2018年

46

これがgpg2に基づく私の解決策です(しかし、gpgにも同様の手法を適用できると思います)

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

これにより、gpg2はキーを完全に信頼するようになり、プロンプトなしで暗号化できるようになります


1
これにより、trust-dbがすぐに更新され、保存は必要ありません。
レーン

12
これにより、キーの有効性ではなく、所有者の信頼が設定されます。究極の信頼はあなた自身の鍵のためだけです。つまり、Ultimately Trusted Identityによって署名されたものはすべて、自分自身によって署名されたものとして処理されます。したがって、それがあなたの鍵でない場合は、信頼を究極に設定しないでください。問題はキーの有効性です。これを解決/回避するには、キーに署名する必要があります。(ローカルのみの署名と指紋認証を検討してください)
x539 2014

3
x539は正しいです。gpg2 --edit-key <key-id>あなたがした後lsignsave。トラスト5はこれを間違って使用していると思います(誤解されています)。x539が言ったことから、(私にとっては)効果がなかった(役に立たなかった)のです。
n611x007 2016年

これは通常の場合gpgにも機能することに注意してくださいgpg2:)
Markus20年

10

ハックアプローチ:

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

根本的な問題は、USER用に持っているキーが署名されていないことです。信頼できる場合は、で署名できます

gpg --edit-key USER sign

構成によっては、おそらくいくつかの質問があります。これを1回実行すると、crontabに移動できます。私が提案したソリューションを使用して、パスフレーズを別のファイルに入れ、コマンドを実行する1人のユーザーだけが読み取れるようにすることをお勧めします。そうすれば、を殺すことができyes |、暗号化ラインを持っているだけです。


1
gpg2 --edit-key USER signの両方のsignkeyメソッドを試しましたが、署名されていることが示されていますが、trust:unknownのままです。そして、バッチはプロンプトなしではまだ実行されません
nycynik 2012

2
lsignはより良い考えだと思います。あなたが署名した場合、それはそうではありません。ローカルでキーに署名します。そのサインはコンピューターに残ります。しかし、単に署名した場合、それは公開されていると見なされるため、--send-keys?を実行するとキーサーバーに送信されます。
n611x007 2016年

2

このコマンドを使用してください、それはあなたを助けます

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

1

私もこれに遭遇していました。何か面白いことをするためのサインキーを手に入れることができませんでした。これが私がしたことです:

gpgキーを作成します。

gpg --gen-key

長いキーIDを取得します(結果は5列目にあります):

gpg --list-keys --with-colon name@domain.tld

信頼できるキーラインを〜/ gnupg /gpg.confに追加します

trusted-key 16DIGITALPHANUMERICKEYID

バックアップスクリプトのgpg行:

gpg -e -r name@domain.tld backup_file.tgz

cronのデバッグ:cronコマンドラインでstdoutとstderrをログファイルに送信することで、cronのデバッグ出力もキャプチャしています。知っておくと役に立ちます


1
いいえ、そうしないでください。追加trusted-keyする行gpg.confが発生しますgpg、常にその鍵を信頼し、ユーザー独自の鍵の一つとして完全として悪いことです引数--trusted-keyとして渡す、そしてでのみこの特定の場合に受け入れられます(同じ方法で渡す--trust-model=always場合同様)。
ブラックライトシャイニング2015

それが私の鍵です。私が望むものを正確に信頼できるものとしてマークしていませんか?
jorfus 2016

1
それが実際にあなたの鍵である場合は、はい、それを最終的に信頼できるものとしてマークします(ただし、私は個人的に--edit-keytrusted-key行を追加するのではなく、でそれを行うことを好みます)。質問者は、不平を言っているのは自分の鍵だとは言いませんでしたgpg
ブラックライトシャイニング

1

私のように、多くの人が質問の「キーボード操作なし」の部分のためにここに来ると思います。gpg2とgpg-agentを使用すると、キーボードを操作せずに署名/暗号化/復号化するのが非常に複雑になりました。プレーンテキストの秘密鍵パスフレーズをテキストファイルに保存するときに署名を作成する方法は次のとおりです。

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

必要に応じて-b-s-aを変更します。他のスイッチは必須です。を使用することもできます--passphrase 'SECRET'。すでに指摘したように、それに注意してください。もちろん、平文のテキストファイルはそれほど優れていません。


0

または、キーに署名します(もちろん、指紋を確認した後)。

gpg --sign-key <recipient email address>

その後、あなたは完全に鍵を信頼します。

  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

5
所有者を信頼することは、この問題とは何の関係もありません。他のキーとその所有者の署名/検証に関して所有者を信頼する場合にのみ、所有者の信頼を設定します
x539 2014

Ianesは、キーの信頼について更新するために回答を編集してみませんか?現在、誤解を招く可能性があります...また--lsign-key、より良いアイデアかもしれませんね?lsignに関する他のコメントを参照しください
n611x007

0

ここに画像の説明を入力してください

email-idで初めて証明書を作成するときは、完全に信頼できる証明書を選択してください。そうすれば、ファイルを暗号化するたびに、次のような質問は表示されません。詳細については、上記のリンクの画像を開いてください。

キーがユーザーIDで指定された人のものであるかどうかは定かではありません。あなたが本当に自分が何をしているのか知っているなら、次の質問に「はい」と答えることができます。

とにかくこのキーを使用しますか?(y / N)


0

別のアプローチ:(サードパーティのキーを使用して暗号化するのではなく)機密データへのアクセス拒否するために、データを保護するサーバーに** PUBLICキーのみをアップロードし、そのキーを使用して暗号化します。これは、対話型プロンプトを供給するためのパスワードの促進の自動化の必要性を否定し、すべての最高は、PRIVATE鍵は、公開サーバーから離れています。

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

ただし、独自の公開鍵で暗号化しない場合、スイッチの使用は--trust-model always少し厄介です。とにかく、データへのアクセスを拒否する問題を解決する別の方法。HTH-テレンスフーラハン

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.