Skip to content

gpg: rejected by import filter

Trying to import a GPG key failed:
$ gpg --verify SHA512SUMS.asc
gpg: Signature made Thu Dec  4 18:03:53 2014 PST using RSA key ID 15A0A4BC
gpg: Can't check signature: public key not found

$ gpg --recv-keys 15A0A4BC
gpg: requesting key 15A0A4BC from hkp server keys.gnupg.net
gpg: key 3A06537A: rejected by import filter
gpg: Total number processed: 1
The thing is, 0x15A0A4BC points to a subkey and GnuPG v1.4.18 has problem when only the keyid of the subkey is specified. There are a few ways to tackle that:

Upgrade to at least GnuPG v2.0.26. While the 1.4-branch is said to be maintained, the release notes are not. If you're really using v1.4, make sure that commit d585527 is included, which fixes bug #1680

If updating GnuPG is not an option, we can also download the key and import it locally:
$ curl http://pgp.mit.edu/pks/lookup?op_get_search_0x15A0A4BC 0x15a0a4bc.pub
$ gpg --import 0x15a0a4bc.pub 
gpg: key 3A06537A: public key "Mozilla Software Releases <releases@mozilla.org>" imported
gpg: Total number processed: 1
gpg:               imported: 1  (RSA: 1)
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0  valid:  18  signed:  11  trust: 0-, 0q, 0n, 0m, 0f, 18u
gpg: depth: 1  valid:  11  signed:   3  trust: 11-, 0q, 0n, 0m, 0f, 0u
gpg: next trustdb check due at 2015-03-14
Or, now that we know the real keyid, we can import it too:
$ gpg --yes --batch --delete-keys 0x15a0a4bc

$ gpg --recv-keys 3A06537A
$ gpg --verify SHA512SUMS.asc 
gpg: Signature made Thu Dec  4 18:03:53 2014 PST using RSA key ID 15A0A4BC
gpg: Good signature from "Mozilla Software Releases <releases@mozilla.org>"
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: 2B90 598A 745E 992F 315E  22C5 8AB1 3296 3A06 537A
     Subkey fingerprint: 5445 390E F5D0 C2EC FB8A  6201 057C C3EB 15A0 A4BC

SSH & the while loop

Somehow this loop stops after the first element:
$ head -2 hosts
lt1001
lt1002

$ head -2 hosts | while read a; do ssh $a "uname -n"; done
lt1001
The best explanation I could find, comes from a forum post*):
> The "cat list.txt" is providing stdin for the entire "while" loop. It is not 
> constrained to only the read statement. ssh is eating all of the input
> and feeding it to "date" as stdin. And date just ignores the input. Use
> the -n option to ssh to stop this from happening.
And indeed, this is working now:
$ head -2 hosts | while read a; do ssh -n $a "uname -n"; done
lt1001
lt1002
Thanks, Perderabo!

*) copied w/o permission