Blog O' Matty


Displaying GPG public keys in ASCII format

This article was posted by Matty on 2010-06-22 10:37:00 -0400 -0400

I was debugging a gpg issue earlier this week, and needed to dump the contents of a public key in some type of human readable form. After a bit of googling I came across the crazy awesome pgpdump utility, which provides a command line interface to display the contents of a GPG public key. To use this tool, you can pass the key file as an argument to pgpdump:

$ gpg --export -a > HOME/pub.asc

$ pgpdump HOME/pub.asc

Old: Public Key Packet(tag 6)(418 bytes)
Ver 4 - new
Public key creation time - Tue Jun 22 10:33:25 EDT 2010
Pub alg - DSA Digital Signature Algorithm(pub 17)
DSA p(1024 bits) - ...
DSA q(160 bits) - ...
DSA g(1021 bits) - ...
DSA y(1023 bits) - ...
Old: User ID Packet(tag 13)(31 bytes)
User ID - Test Key
Old: Signature Packet(tag 2)(96 bytes)
Ver 4 - new
Sig type - Positive certification of a User ID and Public Key packet(0x13).
Pub alg - DSA Digital Signature Algorithm(pub 17)
Hash alg - SHA1(hash 2)
Hashed Sub: signature creation time(sub 2)(4 bytes)
Time - Tue Jun 22 10:33:25 EDT 2010
Hashed Sub: key flags(sub 27)(1 bytes)
Flag - This key may be used to certify other keys
Flag - This key may be used to sign data
Hashed Sub: preferred symmetric algorithms(sub 11)(5 bytes)
Sym alg - AES with 256-bit key(sym 9)
Sym alg - AES with 192-bit key(sym 8)
Sym alg - AES with 128-bit key(sym 7)
Sym alg - CAST5(sym 3)
Sym alg - Triple-DES(sym 2)
Hashed Sub: preferred hash algorithms(sub 21)(3 bytes)
Hash alg - SHA1(hash 2)
Hash alg - SHA256(hash 8)
Hash alg - RIPEMD160(hash 3)
Hashed Sub: preferred compression algorithms(sub 22)(3 bytes)
Comp alg - ZLIB (comp 2)
Comp alg - BZip2(comp 3)
Comp alg - ZIP (comp 1)
Hashed Sub: features(sub 30)(1 bytes)
Flag - Modification detection (packets 18 and 19)
Hashed Sub: key server preferences(sub 23)(1 bytes)
Flag - No-modify
Sub: issuer key ID(sub 16)(8 bytes)
Key ID - 0xA7B71783E5016F25
Hash left 2 bytes - ad 6b
DSA r(157 bits) - ...
DSA s(159 bits) - ...
-> hash(DSA q bits)
Old: Public Subkey Packet(tag 14)(525 bytes)
Ver 4 - new
Public key creation time - Tue Jun 22 10:33:25 EDT 2010
Pub alg - ElGamal Encrypt-Only(pub 16)
ElGamal p(2048 bits) - ...
ElGamal g(3 bits) - ...
ElGamal y(2046 bits) - ...
Old: Signature Packet(tag 2)(73 bytes)
Ver 4 - new
Sig type - Subkey Binding Signature(0x18).
Pub alg - DSA Digital Signature Algorithm(pub 17)
Hash alg - SHA1(hash 2)
Hashed Sub: signature creation time(sub 2)(4 bytes)
Time - Tue Jun 22 10:33:25 EDT 2010
Hashed Sub: key flags(sub 27)(1 bytes)
Flag - This key may be used to encrypt communications
Flag - This key may be used to encrypt storage
Sub: issuer key ID(sub 16)(8 bytes)
Key ID - 0xA7B71783E5016F25
Hash left 2 bytes - b1 38
DSA r(158 bits) - ...
DSA s(159 bits) - ...
-> hash(DSA q bits)

Pgpdump will display the algorithms used to create the key, as well as the key-lengths that were used. This is amazingly helpful when debugging key-related issues (hash algorithm mismatches, key-size discrepancies, etc.), and I will definitely be adding this tool to my SysAdmin toolkit!

Getting notified when new hosts appear on your network

This article was posted by Matty on 2010-06-05 09:01:00 -0400 -0400

I had to debug an interesting network problem a few weeks back, and wanted to see when new hosts appeared on my network. While debugging the issue, I needed to find a way to get notified when a new host appeared (I didn’t want to sit at a terminal reviewing the output from snoop and tcpdump). Enter arpwatch, which can be used to send alerts the first time a client issues an ARP request. This is actually quite handy, and the alerts you get my e-mail are rather useful:

$ arpwatch -i br0

From: root (Arpwatch)
To: root
Subject: new station

hostname: foo.bar.com
ip address: 192.168.1.18
ethernet address: 0:1c:b3:c2:80:2f
ethernet vendor:
timestamp: Friday, April 30, 2010 23:07:32 -0400

There are a slew of options to control who gets the e-mail, whether to use a saved packet capture instead of an active network connection, etc. Arpwatch is a pretty cool tool, and saved me a lot of time and hassle!

ARM vs. Intel Atom comparison

This article was posted by Matty on 2010-05-31 07:49:00 -0400 -0400

Van Smith wrote an awesome articlecomparing current ARM processors and their lower power consuming x86 friends such as the Intel Atom.

Here’s the conclusion of his performance benchmark tests:

“The ARM Cortex-A8 achieves surprisingly competitive performance across many integer-based benchmarks while consuming power at levels far below the most energy miserly x86 CPU, the Intel Atom. In fact, the ARM Cortex-A8 matched or even beat the Intel Atom N450 across a significant number of our integer-based tests, especially when compensating for the Atom’s 25 percent clock speed advantage.”

However, the ARM Cortex-A8 sample that we tested in the form of the Freescale i.MX515 lived in an ecosystem that was not competitive with the x86 rivals in this comparison. The video subsystem is very limited. Memory support is a very slow 32-bit, DDR2-200MHz.

Languishing across all of the JavaScript benchmarks, the ARM Cortex-A8 was only one-third to one-half as fast as the x86 competition. However, this might partially be a result of the very slow memory subsystem that burdened the ARM core.

More troubling is the unacceptably poor double-precision floating-point throughput of the ARM Cortex-A8. While floating-point performance isn’t important to all tasks and is certainly not as important as integer performance, it cannot be ignored if ARM wants its products to successfully migrate upwards into traditional x86-dominated market spaces.”

Sending alerts to your Linux desktop when things go wrong

This article was posted by Matty on 2010-05-30 08:44:00 -0400 -0400

I run gnome on my work desktop, and even with our various monitoring solutions I still use some custom notification tools to get alerted when specific issues occur. One of these tools is gnome-notify, which allows you to create a visible notification inside your desktop workspace. This tool has several useful options, which are displayed when you run notify-send with the “-?” option:

$ /usr/bin/notify-send -?

Usage:
/usr/bin/notify-send [OPTION...] [BODY] - create a notification

Help Options:
-?, --help Show help options

Application Options:
-u, --urgency=LEVEL Specifies the urgency level (low, normal, critical).
-t, --expire-time=TIME Specifies the timeout in milliseconds at which to expire the notification.
-i, --icon=ICON[,ICON...] Specifies an icon filename or stock icon to display.
-c, --category=TYPE[,TYPE...] Specifies the notification category.
-h, --hint=TYPE:NAME:VALUE Specifies basic extra data to pass. Valid types are int, double, string and byte.
-v, --version Version of the package.

To use this tool to send an alert when a fault is detected, I typically wrap some conditional logic to parse the output of one or more commands:

system_check=$(...)

if [ "${system_check}" = "1" ] then;
    /usr/bin/notify-send -t 10000 -u critical "Problem with server X"
fi

The code above will run the command embedded inside $(), and capture the output from this command in the variable system_check. If the value of the output is 1, then notify-send will be invoked to send a notification with the string “Problem with server X” to my desktop. The real value of notify-send comes when you combine it with the clusterit tools, and generate notifications based on the result of running a command across ALL of your servers. Nice!

Sending commands to multiple Linux and Solaris machines through a single graphical shell window

This article was posted by Matty on 2010-05-29 09:15:00 -0400 -0400

I have been a long time user of clusterssh, which is a fanstastic tool for sending commands to multiple hosts. Inside each terminal window you can type a command, or you can use the master console to send a command to all of the windows you opened. The clusterit tools comes with a similar tool, dvt, which is quite similar to clusterssh. Dvt uses the CLUSTER variable just like dsh and company, and has a master console that allows you to send commands to each server in that list. To use dvt, you will first need to create a list of hosts you want to connect to:

$ cat /home/matty/cluster/nodes
foo1 foo2 foo3

Once you have a list of hosts, you will need to export this list through the CLUSTER variable:

$ export CLUSTER=/home/matty/cluster/nodes

After these two items have been completed, you can run dvt to create an xterm on each server (click here to see what this looks like). You can then type in each terminal window, or use the master window to send the same command to all of the windows you have opened. This is another awesome tool that every SysAdmin should have in their tool belt, and it’s easy to install clusterit!