I followed instruction on this page to verify the integrity of the download file. The file is a Sqoop installation, but my question is not specific to Sqoop.
http://www.apache.org/dyn/closer.lua/sqoop/1.4.7
At the backup site page I downloaded two files - asc file and md5 file.
https://www-eu.apache.org/dist/sqoop/1.4.7/
The instruction said I need to download KEYS file, PGP signature file (asc file), or PGP hash file (md5). So I think for this particular download there is no KEYS file?
I used the following command in CentOS, verifying the file with hash.
gpg --print-md MD5 sqoop-1.4.7.bin__hadoop-2.6.0.tar.gz
I got the hash value, which matches to the downloaded md5 file by characters, but NOT by case.
So question #1: Is PGP Hash verification case-insensitive?
In addition, Question #2: because there is no KEYS file to download, how do I use the asc file to verify file integrity? I tried the command on the instruction page but none of them worked for me.
Related
I have a zip file with the size 1 GB on S3 bucket. After downloading, I can't seem to unzip it. It always says
End-of-central-directory signature not found. Either this file is not
a zipfile, or it constitutes one disk of a multi-part archive. In the
latter case the central directory and zipfile comment will be found on
the last disk(s) of this archive.
Later, I download it again, using s3cmd this time. It says
WARNING: MD5 signatures do not match: computed=384c9a702c2730a6b46d21606137265d, received="b42099447c7a1a390d8e7e06a988804b-18"
Is there any s3 limitation I need to know or this is a bug?
This question seems dead, but I'll ask it for anyone landing here:
Amazon S3's multipart uploads (those suitable for big files) produce ETag values which no longer matches file's MD5, so if you're using this as checksum (as it seems looking at your received MD5) it won't work.
Best you can do for validation is ensuring ContentMD5 header is added to every part's header on your multipart upload ensuring file does not get corrupted during upload, and adding your own MD5 metadata field for checking data after download.
Thanks #ergoithz for reminding me that I had this question :)The problem is already fixed, with AWS SDK for nodejs being the problem. Apparently it cannot upload large files using stream data fs.createReadStream(), so I switched to using Knox where it worked perfectly
Does anyone know how to transition authentications on NTP? I've done copious amounts of research, none being fruitful. For example, NTP currently using MD5, how do you move over to SHA1?
NTP if compiled along with OPENSSL libraries, then NTP uses OPENSSL libraries for cryptographic operations.
Then you can use different types of message digest algorithms supported by OPENSSL. This is a link which explains configuring ntp key file.
The key file where the keys will be present should be added to the /etc/ntp.conf file.
The keys to be used for generating the digest will be present under
/etc/ntp/keys . This path should be added to /etc/ntp.conf file to specify that this is the keys file.
The structure of the entry in the file will be
This is an example of the keys file
You can mention the keytype as "SHA1" to use SHA1 authentication.
Further details about the length of the digest and keys can be found here:
https://www.eecis.udel.edu/~mills/ntp/html/authentic.html
You can have multiple keys one next to the other.
SO:
first add the new key everywhere
delete the old key once it's added everywhere.
I have a PPK file and I am trying to have PuTTY use it, when I am connecting to a remote server. But I keep getting this error below, and then I am just asked for my username (while I should be directly allowed in as root).
I don't understand what the problem is, and what's worse I have no idea how to troubleshoot further. A colleague of mine is using the same file and says everything is OK on his side. So I am stuck.
I did a web search and all I find is recommendations to convert the PEM file into a PPK file. But that does not apply in my case, I already have a PPK file.
I am using Windows on my local machine and the PPK file is located in C:\ssh-keys\
Unable to use key file "C:\ssh-keys\filename.ppk" (not a private key)
login as:
Here is the header:
filename.ppk
ё : mBIN ‚Ѓ& PuTTY-User-Key-File-2: ssh-rsa
Encryption: none
Comment: imported-openssh-key
Public-Lines: 6
Your key file is corrupted.
A .ppk file must start with the PuTTY-User-Key-File- followed by the ppk format version number. It must be a plain text file. No binary data. No UTF BOM. Your colleague must have a different (correct) copy of the file.
I'm trying to understand how a .pem file is laid out. How is the passphrase authenticated? How does the .pem file check against itself the passphrase you try to open it with?
Multiple different kinds of data are stored in files with the extension .pem. So your question is imprecise. But suppose it is a password-protected private key file. Why do you believe the password is stored anywhere in it? In fact it is not stored in the file. The passphrase is used to generate a symmetric key, which is used to decrypt the file and check the decrypted file for consistency.
I am using dozens of different web services, and I keep a password file in a remote Linux machine. The file contains my usernames, passwords and answers for security question.
This server happens to be offline to often, and I'm looking for a way to keep the password file on my own computer, or on a service like DropBox. Obviously, I want to keep the file encrypted, but handy - I want to be able to print its contents using one shell (or cygwin) command, perhaps using a passphrase.
Any good ideas how to do it?
You can use GPG's symmetric option to encrypt files with pass-phrases.
gpg --symmetric filename
That will result in an encrypted file named filename.gpg. To redirect the output to STDOUT instead of a .gpg file:
gpg --symmetric -o - filename
You can later decrypt the file with:
gpg --decrypt filename.gpg
I use PasswordSafe encrypted files in exactly this configuration. GUIs are available for Windows/Mac/Unix/Java. cliPSafe gives it a command line interface.
THe original code was written by Bruce Schneier, well known in the security world, but I've never used cliPSafe.
As already noted GPG solves the problem. Using the gpg command directly for encrypting text files may be a bit cumbersome though, especially as you would often decrypt the file to a seperate file, add some text (passwords in this case) and the reencrypt it (which will possibly expose your unencrypted data).
Vim has a very good plugin called gnupg for trasparently handling encrypted files using GPG. Using this plugin the unencrypted data will never be written to disc and you can just treat it as any other file (except for the passphrase question popping up of course).