from the following URL I have downloaded the YubiHSM SDK https://developers.yubico.com/YubiHSM2/Releases/.
However the other URL says we need to validate the package by downloading the keys which is specified from the following URL:https://developers.yubico.com/Software_Projects/Software_Signing.html
However what is the keyserver do we need to use to download a key?
I will be using the following command to receive a key:
gpg --keyserver pgp.mit.edu --recv-keys 70D7145F2F35C4745501829A1B21578FC4686BFE
And the command output is as following:
gpg: keyserver receive failed: Server indicated a failure
Regards,
Sudheer
PGP key servers synchronise their keys so it shouldn't matter which one you use. Also, your system should be configured already to use a pool of key servers, so the --keyserver option is not required.
Try without the --keyserver option.
If that doesn't work, try with an alternative key server. For instance keyserver.ubuntu.com, sks.pgpkeys.eu, or keys.openpgp.org.
Related
I generated a key pair using GPG by following command in Debian 8.
gpg --gen-key
I left the passphrase step of key generation empty and just hit the Enter key. After that, I exported private and public key using following commands.
gpg --export-secret-key -a "X" > private.key
gpg --export-key -a "X" > public.key
Then I tried to encrypt a folder using the private key. It was successful and without asking any passphrase the encrypted file was generated.
But When I transferred the public key to another computer with Ubuntu OS 14.04 and import it using following command, gpg requested passphrase. Even, by giving empty passphrase to gpg, it says that passphrase is incorrect.
gpg --import public.key
Furthermore, when I imported the private key in the second computer for encryption, it asks me passphrase again.
Does anyone have any idea what is the problem?
There is no need to export and import keys. Just copy the key files located in ~/.ssh/ on your source machine to the other system.
It was because there exist other keyring in second system before. Indeed, it is required to clear all keys before import
When running the following command on OpenVAS 7 under root (where gb_iojs_detect_win.nasl is one of the OpenVAS plugins. other plugins cause the same error):
openvas-nasl gb_iojs_detect_win.nasl
causes this error:
base gpgme-Message: Setting GnuPG homedir to '/usr/local/var/lib/openvas/gnupg'
base gpgme-Message: Using OpenPGP engine version '1.4.16'
base gpgme-Message: Setting GnuPG sysconf homedir to '/usr/local/etc/openvas/gnupg'
gb_iojs_detect_win.nasl: bad or missing signature. Will not execute this script
Note that i did follow this page and set nasl_no_signature_check = yes, but this error still persists.
Thanks! Any help would be appreciated!
Execute the following and follow the prompts:
gpg --homedir=/usr/local/etc/openvas/gnupg --gen-key
Then execute:
wget http://www.openvas.org/OpenVAS_TI.asc -P /tmp
gpg --homedir=/usr/local/etc/openvas/gnupg --import /tmp/OpenVAS_TI.asc
gpg --homedir=/usr/local/etc/openvas/gnupg --list-keys
gpg --homedir=/usr/local/etc/openvas/gnupg --lsign-key 48DB4530
Source: http://www.openvas.org/trusted-nvts.html
Do what indicated above and update your feeds plugins
I also struggled with this, due to the documentation falling short.
You need to provide the -X flag, which means authenticated mode, which apparently means "Don't do the signature checks"
I was having this issue with OpenVAS 9, but based on the instructions from #D.W., I read the docs about trusted NVTs, they mention that they're going to start using a new key starting 12/1/18.
However, when I ran openvassd -f to see what it was doing, I noticed that there were only some plugin checksums that were failing, and I'm thinking they're already signing these with the new key.
checksum for /var/lib/openvas/plugins/gb_electrasoft_32bit_ftp_detect.nasl not matching
checksum for /var/lib/openvas/plugins/gb_atlassian_confluence_detect.nasl not matching
checksum for /var/lib/openvas/plugins/gb_synology_dsm_detect.nasl not matching
checksum for /var/lib/openvas/plugins/gb_quixplorer_detect.nasl not matching
checksum for /var/lib/openvas/plugins/gb_yealink_ip_phone_detect.nasl not matching
checksum for /var/lib/openvas/plugins/secpod_neon_detect.nasl not matching
checksum for /var/lib/openvas/plugins/gb_torrent_trader_classic_detect.nasl not matching
checksum for /var/lib/openvas/plugins/gb_simatic_s7_snmp_detect.nasl not matching
checksum for /var/lib/openvas/plugins/gb_sophos_xg_detect_userportal.nasl not matching
checksum for /var/lib/openvas/plugins/gb_keycloak_detect.nasl not matching
checksum for /var/lib/openvas/plugins/gb_wd_wdtv_detect.nasl not matching
checksum for /var/lib/openvas/plugins/gb_get_http_banner.nasl not matching
checksum for /var/lib/openvas/plugins/gb_orion_nta_detect.nasl not matching
checksum for /var/lib/openvas/plugins/gb_gather_windows_uptime.nasl not matching
checksum for /var/lib/openvas/plugins/gb_teleopti_wfm_detect.nasl not matching
checksum for /var/lib/openvas/plugins/gb_asp_dotnet_core_detect_win.nasl not matching
checksum for /var/lib/openvas/plugins/eggdrop_detect.nasl not matching
checksum for /var/lib/openvas/plugins/gb_f5_linerate_lros_version.nasl not matching
checksum for /var/lib/openvas/plugins/gb_mikrotik_router_routeros_consolidation.nasl not matching
However, the fix was to just use the same instructions (had to modify paths for config directory for Ubuntu/Debian), but with the newer key. After that the checksums were validated OK:
wget https://www.greenbone.net/GBCommunitySigningKey.asc -P /tmp
gpg --homedir=/etc/openvas/gnupg --import /tmp/GBCommunitySigningKey.asc
gpg --homedir=/etc/openvas/gnupg --list-keys
gpg --homedir=/etc/openvas/gnupg --lsign-key 0ED1E580
systemctl restart openvas-scanner.service
Your command should be like this:
openvas-nasl -Xp gb_iojs_detect_win.nasl #for parsing
openvas-nasl -Xt IP gb_iojs_detect_win.nasl #for exec
note the additional switches.
For more details, visit this link
I have a job that runs periodically and signs/encrypts a file like so:
$ gpg --homedir /path/to/.gnupg -r key1#mydomain.com -r key2#mydomain.com --local-user sig1#mydomain.com --batch --passphrase-file /path/to/gpg-password --sign -ea myfile
The command encrypts the file for two recipients: key1#mydomain.com and key2#mydomain.com. It signs the file with sig1#mydomain.com. It runs in batch mode as there is no human interactivity - this is an automated process. It gets the passphrase for the signature from /path/to/gpg-password.
What I would like to do is now sign the file with two signatures at the same time. Like so:
$ gpg --homedir /path/to/.gnupg -r key1#mydomain.com -r key2#mydomain.com --local-user sig1#mydomain.com --local-user sig2#mydomain.com --batch --passphrase-file /path/to/gpg-password --sign -ea myfile
gpg: skipped "sig2#mydomain.com": bad passphrase
It works fine in interactive mode (eg. without --batch), I just have to supply the two passphrases via the command line. However, in batch mode it fails as it tries to get the signatures from the file. The signature is only valid for one of the signing keys.
From the man page:
--passphrase-file file
Read the passphrase from file file. Only the first line will be read from file file. This can only be used if only one passphrase is supplied.
How do I tell it what the password is for each key?
You have different options.
Completely remove the passwords, since they're stored somewhere anyway.
Use the same password (as you already discovered).
Use the gpg-agent and preset the passphrase. I'm unsure whether this is GnuPG 2-only (usually installed as gpg2, maybe to be installed from a gnupg2 package). Presetting the passphrase is as easy as running gpg-preset-passphrase --preset [fingerprint]. You will have to run this command for each of the keys individually, and make sure to cache the passphrase for a given time (at least the processing time of adding all the passphrases, and then signing the file you want to sign).
For the sake of completeness, but impractical: sign the file individually for each key, then take apart the OpenPGP packets and recombine them adding all the signatures one after the other. Signing with multiple keys just creates multiple signature packets.
For anyone else in the same situation as me, I ended up working around this apparent deficiency of gpg by editing one of the signing keys to have the same password as the other (the password stored in the gpg-password file). This doesn't compromise security in this instance since the password is stored in a text file anyway - the real security is the password of the user that this commands runs from and the fact that the secret keys are kept secret). You can change the password on a key by doing gpg --edit-key <key_id>, then passwd. Don't forget to save after.
I encryptd a file using gpg, now I want to decrypt the file.
Is there any way to decrypt the file without need to import the secret file?
We have the secret key in a file called key.sec; can we pass the secret file to gpg as a parameter (when we run the decrypt command from the bash command line) to use when decrypting the encrypted file? Or must we import the secret key then decrypt the encrypted files?
You must add the secret key to a keyring. From the gpg(1) documentation:
--no-default-keyring
Do not add the default keyrings to the list of
keyrings. Note that GnuPG will not operate without any
keyrings, so if you use this option and do not provide
alternate keyrings via --keyring or --secret-keyring,
then GnuPG will still use the default public or secret
keyrings.
You could --import --no-default-keyring --secret-keyring temporary to import the key, use --secret-keyring temporary when decrypting the content, then delete the ~/.gnupg/temporary.gpg file when you're done. But that's just a work-around.
You have to import the secret key to use it but the way that secret keys are managed by GnuPG version 2.x has changed. There is a gpg-agent daemon that handles secret keys access and its use is mandatory from version 2.1.
Here is a way that you can quickly create a temporary keyring to decrypt with a secret key that is contained in a file:
$ mkdir -m 700 ~/.gnupg-temp
$ gpg --homedir .gnupg-temp --import key.sec
$ gpg --homedir .gnupg-temp -d an_ecrypted_file
If you want to clean up afterwards, stop the agent and remove the directory:
$ gpg-connect-agent --homedir .gnupg-temp KILLAGENT /bye
$ rm -r ~/.gnupg-temp
There used to be an option --secret-keyring about which the documentation for version 2.1 has this to say:
This is an obsolete option and ignored. All secret keys are stored in the private-keys-v1.d directory below the GnuPG home directory.
The private-keys-v1.d directory (wthin the --homedir or ~/.gnupg) is owned and operated by the agent.
The objective of the OP Mohammed appears to be keeping his PUBLIC and SECRET key apart. After all, do we want to keep the Secret key with the data it was used to encrypt? Thus, Mohammed's and 10,650+ others (at the time I write this) are interested in if/how it's possible. Indeed it is, and this is how you do it:
The publicly-facing host only has two keys: Both are Public Keys
Your GPG Public key used to encrypt data
Your SSH Public key in .ssh/authorized_keys to facilitate non-interactive logins.
Round-tripping an encrypted file using Public-Secret key separation:
The following bash snippet when executed on the host with the Secret Key will fetch the crypted file from the DMZ host via scp, and squirt the gpg decrypted standard output back onto the DMZ host into a file so it can be read/operated upon. This code is tested and known to work correctly:
echo "$(gpg -d $(scp myuser#192.168.1.10:/home/myuser/test-gpg.txt.asc .;ls ./test-gpg.txt.asc))" | ssh myuser#192.168.1.10 'cat > /home/myuser/test-gpg.txt'
Note that you will still be prompted for a password once decryption begins. But once the password is supplied, the script continues and injects the decrypted gpg stream into a file on DMZ host.
And don't forget to do an rm test-gpg.txt of the decrypted file once the operation that required it's contents to be readable has been completed.
So yes, very possible to keep your secret key apart from the publicly accessible host where encryption occurs and your secret key tucked safely away in a host outside of that DMZ. HTH- Terrence Houlahan
When I try to encrypt the password by using the following command on my linux machine:
slappasswd -h {CRYPT}
I am prompted for a new password:
Re-enter the new password :
After typing this I encounter the following error:
Password generation failed for scheme {CRYPT}: scheme not recognized.
Why am I getting this error? I am using the OpenLDAP.
this might be caused by your shell (tcsh?) treating the {} characters special. does
slappasswd -h '{CRYPT}'
work?
also, your openldap must be built with crypt support ($LDAP_SRC/configure --enable-crypt):
ldd /usr/sbin/slappasswd | grep libcrypt
(adapt the path to slappasswd as necessary) should output something.
it could be simply that your version of openLDAP does not support the use of the CRYPT encryption scheme.
you can instead use, for instance, SSHA:
slappasswd -h {SSHA}
i had the same problem, using LDAP 2.4.33 on CentOS 6.3.