Here's a quick hack for generating a very secure passphrase using GnuPG itself. The passphrase will not be easy to remember or type, but it will be very secure. The hack generates 16 random binary bytes using GnuPG then converts them to base64, again using GnuPG. The final sed command strips out the headers leaving a single line that can be used as a passphrase:
gpg --gen-random 1 16 | gpg --enarmor | sed -n 5p
Instead of using gzip to compress tarballs, use GnuPG. The tarballs will end up being about the same size, but they also will be encrypted. By the way, don't bother trying to gzip or otherwise compress any encrypted files. Encrypted data is usually incompressible. This is because data compression and encryption are closely related mathematically. Because of this, most cryptosystems, GnuPG included, automatically compress before encryption. There is also a slight gain in security by compressing.
You will be prompted for a passphrase twice, just like when encrypting before:
tar -cf - these files here | gpg -c > these-files-here.tgp
To extract the files, enter the password entered above:
gpg < these-files-here.tgp | tar -xvf -
If you want to use GnuPG in a script and don't want to be prompted for the passphrase, put the passphrase in a file called passphrase.txt, and use this to encrypt:
[$ cat passphrase.txt | gpg --passphrase-fd 0 -c < filename.txt > filename.gpg
Note: decrypting is nearly identical, simply drop the -c and switch the files around:
$ cat passphrase.txt | gpg --passphrase-fd 0 < filename.gpg > filename.txt
If you're going to e-mail the encrypted file, perhaps for off-site backup, add the -a option to turn on ASCII armor. The net effect is the same thing as --enarmor used earlier, but it includes encryption. This also produces smaller files than uuencoding or MIME, because by default, GnuPG compresses data before encryption.
To finish off the hack, we also mail the encrypted file at the same time. Note the use of -o - to force GnuPG's output to stdout:
$ cat passphrase.txt | gpg --passphrase-fd 0 -ac -o - filename.txt | mail email@example.com
By the way, putting the passphrase in a file can be extremely dangerous. Anyone who obtains a copy of that passphrase file can then decrypt any file it has ever encrypted. Someone even could create new files with the same passphrase, resulting in secure and undetectable forgery. Make sure your passphrase file, indeed the entire computer, has the security you expect.
Automating tasks inherently requires cutting humans out of the loop, so this security weakness is difficult to avoid. However, GnuPG can help even here by using public key encryption.
Do you have an OpenPGP-encrypted file, but no key ring and no idea what to do with it? Perhaps someone sent you an encrypted file and assumed you would know what to do. Maybe he or she doesn't know what to do either.
If the file has either a .pgp or .gpg extension, you can try decrypting it with GnuPG. Also, check the file with a text editor to see if it contains something like this:
-----BEGIN PGP MESSAGE----- Version: GnuPG v1.2.5 (GNU/Linux) jA0EAwMCwg21r1fAW+5gyS0KR/bkeI8qPwwQo/NOaFL2LMXEYZEV9E7PBLjjGm7Y DGG4QnWD5HSNOvdaqXg= =j5Jy -----END PGP MESSAGE-----
If it does, it's an ASCII-armored PGP-encrypted file.
This particular file is a real encrypted file containing the same value as used in the --print-md examples above and is encrypted with a passphrase of the same value.
Simply running GnuPG on an unknown file produces some useful information. If it prompts you for a passphrase, you'll need to get (or guess) the passphrase used to encrypt the file:
If it's not an OpenPGP file, you'll get something like this:
gpg: no valid OpenPGP data found. gpg: processing message failed: eof
If you get something else, however, maybe the file is encrypted with a public key that you don't have. The file also could be corrupted. A common mistake is to send binary files through e-mail or FTP transfer in ASCII mode.
GnuPG has a special diagnostic option to help troubleshoot these problems. The OpenPGP message format is internally formatted as packets; the --list-packets option dumps out information about those packets:
gpg --list-packets unknown_file.gpg
In addition to the standard information, this option also prints the full key ID of the public key that the file is encrypted with, if any, and what algorithms were used. It could be that the file was encrypted with a PGP 2.x public, sometimes called a legacy key. PGP 2.x predates the OpenPGP standard, so the standard GnuPG cannot decrypt it. Most PGP implementations made in the past several years are usually OpenPGP-compatible, so merely asking the sender to generate a compatible OpenPGP-encrypted file should do the trick.
There also are several different cryptographic algorithms supported by OpenPGP. Most have only some of these algorithms implementationally. Use gpg --version to see what might be missing.
Details on the packet format, such as the internal algorithm numbers, can be found in the OpenPGP standard RFC 2440.
Table 2. A short list of GnuPG options mentioned in the article.
|Short Option||Long Option||Description|
|--version||Version and algorithm information|
|-a||--armor||Turn on ASCII encoding when encrypting|
|--enarmor||Input binary, output ASCII|
|--dearmor||Input ASCII, output binary|
|--print-md HASH||Print a message digest using the specified HASH|
|-c||--symmetric||Conventional symmetric encryption with a passphrase|
|-o||--output||Specify a particular output file, use - for stdout|
GnuPG mostly uses long command-line options, but some options also have short single-letter options from the original PGP. For example, -v is --verbose, not --version.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Introduction to Named Pipes
- Scriptwriting for ze Web and Everywhere Else
- Using tshark to Watch and Inspect Network Traffic
- diff -u: What's New in Kernel Development
- Securing Your Network against Kazaa
- Perceptions of the Linux OS Among Undergraduate System Administrators
- Kernel Korner
- Letters to the Editor
- Making TeX Work
- New Products
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide