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
Related
Having a pipeline with a stage that executes a script that is supposed to decrypt a key file, the GitLab Runner fails:
$ scripts/decrypt.sh $LWCMAP_SERVER_KEY
bad decrypt
139810674749504:error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt:../crypto/evp/evp_enc.c:536:
ERROR: Job failed: exit code 1
The $LWCMAP_SERVER_KEY contains a passphrase that is used to decrypt the key inside a folder, using the following command in the .gitlab-ci.yml:
- scripts/decrypt.sh $LWCMAP_SERVER_KEY
And the content of the shell script is just the OpenSSL command to decrypt the file:
openssl aes-256-cbc -k $1 -in assets/server.key.enc -out assets/decripted_server.key -d
I wonder why the job fails with "bad decrypt" since the exact same command executes just fine locally. I even calculated the md5 of both the file and the key used on decryption, and they are the exact same on the runner and locally (which means it is not corrupted data).
Any ideas?
Edit:
Locally openssl version outputs "LibreSSL 2.8.3", and on the server, I upgraded it to the same version. On the Runner's container though, the output is "OpenSSL 1.1.0j 20 Nov 2018".
So I think I figured why, and what to do to fix..
It does seem like LibreSSL 2.8x is incompatible with OpenSSL 1.1x.
This means that files encrypted on one TLS implementation is unable to decrypt with the other.
What I did instead, was to ssh into the Ubuntu VM then run the encryption there. Since the CI is going to be run with any of our Ubuntu VMs and will be deployed on similar machines using similar TLS implementations, I do not anticipate any further problems with key file encryption/decryption.
This means that I would be unable to test decrypt on my local machine though, but I'm sure I can live with that :-)
Am trying to decrypt an encrypted file, I have all the keys in place (secret and public), I don't know why its not generating output file. Following are the commands am running. I know there are several post already there but I cant refer them until and unless any error flashes on my command prompt.
gpg --list-secret-keys
Its listing secret keys
gpg --list-keys
Its listing all keys
gpg --import "c:\folder_location\name_PublicKey.gpg"
successfully imported keys
gpg --batch --yes --passphrase my_passphrase --local-user "mycomp name
" -o "c:\folder_location\filenameTEST.txt" -d
"c:\folder_location\ENCRYPTEDFILE.txt.gpg"
Am not able to decrypt file on command line, There is no error reported on command prompt. Command remains Active all the time, needed force close.
Anything am missing here to check? any suggestions?
There was no issue with my command, actual problem was CR and LF control characters (new line). When I removed those characters, decryption worked without any errors! GPG never detected these characters and statement got parsed without any error, and later command froze without any error/output.
There is one file I want to encrypt with GnuPG by
gpg2 --homedir=~/.gnupg --always-trust=true --recipient="BlahBlah" --encrypt=/path/to/file --output=/path/to/output_file
However this command seems to hang forever and never return. Interestingly, after I interrupt process, there is indeed /path/to/output_file created , however the bytes written there is much bigger than raw payload (for example my /path/to/file is only of 5 bytes but it turns out there are nearly 200 bytes written to /path/to/output_file).
There must be something wrong, but I really couldn't figure out what is it.
I have in advance imported the key for BlahBlah by gpg --import key.asc. It happens both for GnuPG 1 and GnuPG 2.
You're applying --encrypt in a wrong way. --encrypt does not expect any parameters, the file(s) to be worked on are passed as very last arguments. Additionally, following the documentation you should pass --output /path/to/output_file instead of --output=/path/to/output_file. Finally, GnuPG distinguishes between options and commands, and options should precede commands.
What you observe is that GnuPG starts writing header information, but then waits for input from STDIN (until interrupted).
The GnuPG command line you're looking for is
gpg2 --homedir=~/.gnupg --always-trust=true --recipient="BlahBlah" --output /path/to/output_file --encrypt /path/to/file
One last hint: the combination of --always-trust=true and resolving a recipient by user ID is a very bad idea, as any other key with the same user ID in the local keyring might be used. Pass the full key's fingerprint instead, which specifically selects a distinct key (using short key IDs is not secure, either).
I read on man sshd one can add post-login processing when a user logs in using a particular key:
environment="FOO=BAR" ssh-rsa AAA... keytag
But when I try to ssh into the system, the target host does not register the line and instead asks for a password. What is the right way of adding this? I would like to do something like
command="echo|mail -s ${USER},${HOSTNAME} a.monitored.email#example.com" ssh-rsa AAA... keytag
I am using Suse SLE 11 SP2.
Thanks
Dinesh
First, according to the documentation command = "command":
That specifies the command is executed Whenever This key is used for authentication. The command supplied by the user (if any) is ignored. The command is run on a pty if the client requests a pty; Otherwise it is run without a tty. If an 8-bit clean channel is required, one must not request a pty or specify no-pty Should. A quote May be included in the command by quoting it with a backslash. This option might be useful to restrict Un certain public keys to perform just a specific operation. An example might be a key That Permits remote backups but nothing else. Note That May specify the client TCP and / or X11 forwarding Explicitly UNLESS they 'are prohibited. The command originally supplied by the client is available in the SSH_ORIGINAL_COMMAND environment variable. Note That This option Applies to shell, command or subsystem execution. Also note This command That May be superseded by Either a sshd_config (5) ForceCommand directive or a command embedded in a certificate.
Using this option, it is possible to enforce execution of a given command when this key is used for authentication and no other.This is not what you're looking for.
To run a command after login you can add in the file ~/bashrc something like this:
if [[ -n $SSH_CONNECTION ]] ; then
echo|mail -s ${USER},${HOSTNAME} a.monitored.email#example.com"
fi
Second, you need to verify the permissions of the authorized_keys file and the folder / parent folders in which it is located.
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
For more information see: https://www.complang.tuwien.ac.at/doc/openssh-server/faq.html#3.14
I almost been stuck a day on the following issue,
I installed LDAP using: apt-get install slapd
and use the following configuration:
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/nis.schema
allow bind_v2
loglevel 0
moduleload back_sbdb.la
database bdb
suffix "dc=test,dc=nl"
rootdn "cn=Directory Manager,dc=test,dc=nl"
rootpw test
directory /var/lib/ldap
index objectClass eq
index userPassword eq,pres
index givenName,mail,mobile,sn,title,cn,description eq,sub,pres
index displayName eq,sub,pres
index postalAddress,facsimileTelephoneNumber pres
access to *
by self write
by * read
and I then try to bind using
ldapsearch -D cn=Directory Manager,dc=test,dc=nl -w test
but I still recieve the error ldap_bind: Invalid Credentials (49)
Anyone has any idea or clues what this could be?
Thanks in forward
Try it using quotes like;
ldapsearch -D "cn=Directory Manager,dc=test,dc=nl" -w test
Space character in Directory Manager may cause the problem.
Edit: Also, are you sure you don't need -h -p parameters?
-h The host name of the directory server
-p The port number of the directory server
Edit2: Just figured out what is wrong. You are using rootpw unencrypted in your slapd config file. You should use an encrypted password created by slappasswd tools output. This may cause problems under special circumstances.
Check this link for details: http://www.centos.org/docs/5/html/Deployment_Guide-en-US/s1-ldap-quickstart.html
A few things you could try:
Turn on more verbose logging (loglevel 255), and see if anything shows up in the log file.
Verify that the server really is reading the configuration file you think by checking the access time on the slapd.conf file (ls -lu slapd.conf)
Try binding using an invalid dn (ldapsearch -D cn=no-such-user -w test) and see if the error message changes (if so, that confirms that the problem is with the password, not the dn).
Try man ldapsearch.
I'm not really sure on debian/ubuntu, but in FreeBSD you need to add a -x to use simple authentication instead of SASL. I think this might be your issue?
Also, you could use -W instead of passing the password plain text on the commmand line.