Aaron Toponce

Get Your Unix Beard On

2009-11-01T06:33:37-08:00

Today is the day, my friends. The day where the boys are separated from the men. The day tech support is separated from the system administrators. The day God smiles from on High. What am I referring to? Why, Whiskerino 2009, of course.

The concept is simple. Whiskerino is an Internet beard growing contest that happens biannually on the odd years. As a participant, you take a photo of yourself, and upload it to your account on the site. Other users of the contest will vote on the uploaded pics for the day. The pic with the most votes, becomes King Beard. However, not all is care free. There are some certain rules that you must abide by:

The contest runs from November 1, 2009 to February 28, 2010. You will be required to post a photo of yourself to your account at least once every 7 days.
You must start on Day One completely clean shaven. Sideburns can not extend beyond the earlobe.
You are required to grow a full beard. This means whiskers on the upper lip, cheeks, chin and neck.
You are not allowed to shave the beard until the end of the contest. Trimming, shaping or styling are highly discouraged.
The photo must be of the participant. It is not allowed to be altered in any way. Take the snapshot, and upload it.
Photos must be 4×3 aspect ratio, no smaller than 500px in width. No nudity, profane gestures hateful, imagery, or otherwise offensive content. No more than one image per day can be submitted.
Breaking any of the above rules results in the participant being placed into the Hall of Shame, from which he cannot return. You will be ejected from the contest.
The winner will be chosen by participation in the contest, not just beard growth necessarily. This includes ratings on photos, overall spirit of the contest, attendance and beard style.

So, I’m all in. My wife fully supports my decision (at least until my brother’s wedding in December, of which she might want some trimming or shaping done to the beard). I’ve managed to talk a few of my friends into it as well. So, it will be fun to participate with them, and also make new friends in the contest. I’ve never grown a full beard before. I’ve always been a fan of the circle beard. So, this will be a new experience for me.

Further, every Unix/Linux system administrator should be sporting full beard. It’s part of our culture. It’s who we are. Think of the Greats: Ken Thompson, Dennis Ritchie, Richard Stallman, Alan Cox, Brian Kernighan, and even Steve Jobs (back in the day) all sport beards (c’mon Linus, where’s your Unix beard?). I hope to be able to place my name among them. At least my coworker is fully bearded. Maybe I’ll be able to grasp some of the vast amounts of Unix knowledge from him.

I’ll later post the URL to my Whiskerino profile page. Because the photos are generally meant to be of the creative style for the contest, I’ll be taking that photo, but I’ll also be taking a photo that will suit well for a time lapse “camera”. This will probably go to my Picasa account, which I’ll also provide a link to later. Lastly, for those reading my blog via RSS, you won’t be able to get the benefit of watching the beard growth, unless Whiskerino provides an RSS feed to each profile page. I might post a photo here or there on the blog though. We’ll see. However, there will be a side bar on my blog showing the daily snapshot of my ugly mug.

In the immortal words of William Shakespeare in the play Much Ado About Nothing:

He that hath a beard is more than a youth, and he that hath no beard is less than a man.
~ Beatrice speaking to Leonato

Evil Maid

2009-10-23T06:10:51-07:00

Two weeks ago, we had the Utah Open Source Conference, and I gave a presentation on how to crack passwords when you have physical access to a box. You can find my slides and materials here (3MB tar.gz). As an overview of my presentation, I discussed that if you have physical access to a machine, you can easily get administrative rights (root on Unix-like machines), and as a result, get access to the password database and user accounts, and use software to brute force the passwords out of the database.

I then finished up showing how to break encrypted filesystems using the cold boot attack. The University of Princeton has an excellent white paper, video and software on how to make this possible. The idea is simple- read the contents of RAM immediately after a shutdown, then use software to search through that memory dump finding a passphrase used on the encrypted filesystem. The only problem with this attack, is the limited scope of software in which it is effective against.

Enter Evil Maid.

The idea is simple. Because you still have access to the target machine, rather than doing a cold boot attack, memory dumps and additional processing on the RAM dump, install a different boot loader that contains a key logger. When the target enters the encryption passphrase on his machine, the key logger will have grabbed every key stroke, either saving it somewhere on disk for later retrieval, sending it over the Internet to the attacker, or whatever is necessary to get the passphrase.

THIS WILL WORK ON ANY OPERATING SYSTEM AND IS EFFECTIVE AGAINST ANY FILESYSTEM ENCRYPTION SOFTWARE!

This is more effective than the cold boot attack, or even the “stoned boot” attack that Bruce Schneier covered earlier this year, but it’s still not without its weaknesses. This attack assumes that the target will power on the computer at a later time, and enter the passphrase for the encrypted filesystem. The attacker would not want to actually steal the powered down computer.

This is why it is called “Evil Maid”- you leave your computer in the hotel room, the housekeeping maid comes in to clean your room, but while there, installs the boot loader and key logger, then repowers down your computer. When you return to the hotel room, you power on, enter the passphrase, do you work, or whatever. The next day, when the maid returns, she returns, most likely to either retrieve the key and restore the previous boot loader, erasing her tracks. Now she has access to your data, can image the drive for offline analysis and have all sorts of nasty fun.

This should say something about encrypted filesystems. They really only protect you if the drive is stolen, and the computer has been powered down. Other than that, there is an important security lesson to learn here. If someone has physical access to your computer, with the intent to do harm, there is no stopping them from getting administrative rights on the machine, installing software, archiving data, imaging drives, etc. As a result, this should tell you something valuable: if possible, as in the case with laptops, keep your computer with you in untrusted environments.

There are possible protective measures to protect yourself against such an attack. Storing your computer in a strong box under lock and key might work. Although the attacker only needs to be proficient with lock picks, this is a good first safe measure. Many hotels offer such strong boxes. Second would be hardening your BIOS to help prevent such an attack. Again, just a “speed bump” do a dedicated attacker, but it could be enough to deter. Lastly, because this attack assumes installing software on non-encrypted boot partitions or sectors, getting a hash of the non-encrypted boot partition and storing on a separate USB key could be valuable. Thus, when you travel, before you boot the machine from the hard disk, you could boot from a live CD, and check the hash of the boot sector against the hash stored on your key. Of course, if the attacker ever gets access to your USB key, the hash could be corrupted or modified.

Long story short- don’t leave sensitive data on your machine in untrusted environments, such as hotel rooms. Take your computer with you whenever you can and shut it down when not in use.

A Case For HTML Email – Mashups

2009-10-17T06:09:13-07:00

You know, I had this massive post all typed up arguing why HTML email isn’t inherently evil. Seriously, it was approaching 2000 words. Then I realized something- I’m over complicating the issue. Everything I was trying to say in the post, can be summed up in this video, showing off Ubiquity from Mozilla Labs. Basically, what you are about to see in a couple examples in the video, you can’t do with “plain text” email. This is a video for Ubiquity, which does a lot more, but I think you’ll get the idea.

Ubiquity for Firefox from Aza Raskin on Vimeo.

Now, here’s the funny thing. For those arguing the case for plain text email- you are explicitly putting yourself in a “plain text world”. When someone sends you something, say a mashup of a restaurant review, and you can’t view it with mutt, who’s problem is that? The sender, or the receiver? Think about that for a second. It’s 2009. We should be able to do so much more with email than we’re currently doing, as Aza states, but the plain text folks aren’t interested in that. “Gimme the text, remove the bloat. The web belongs on the web.” they’ll say. Well, I guess the world is interested in passing them by.

Full disclosure- I have been a heavy plain text email advocate in the past. Post 0 and post 1 demonstrate that. Let’s just say I’ve had a change of heart. I want to do more with my email. Also, I’ll be sending all my emails in both plain text and HTML encoding, for those who insist on living in the past as well as for those who actually want to enjoy their email.

Dear Qwest

2009-10-15T21:30:14-07:00

A friend of mine just recently signed up for your land line telephone residential service. Within days, he has already been getting a slew of solicitation phone calls. He hasn’t even had the chance to hand out his number, and already, he’s getting quite the barrage of solicitors. Yet, I have a Google Voice number that hasn’t seen a single unwanted call. I’ve only had it for a few months, but it’s certainly been much, much longer than my friend’s, and I’m handing it to anyone and everyone. I gave it to my school, a car repair shop, Apple Computer, a number of retail shops, friends and family, and so forth. I call tons with it too.

So, can you explain that to me? Why is his fresh number getting spammed, while mine remains completely spam-free? Is selling personal information part of your business plan too? Just curious. Oh, and by the way, I’m not a customer. I left your “Spirit of Service”, because it wasn’t any good.

More ZSH Prompt Love

2009-10-14T07:51:24-07:00

Ever since discovering ZSH 3 years ago, I’ve been addicted, but it wasn’t until a good 2 years into using the prompt on a daily basis that I decided to do some radical work with my prompt. I’ve blogged about this before a couple times, making improvements along the way: post 0, post 1, post 2, post 3. Check out those posts if you’re interested in what I’ve done to the prompt, and extra screenshots.

At the Utah Open Source Conference, I gave a BOF on Unix shells. The turnout was good, and we had a great discussion. I presented on my default prompt for ZSH, showing all the hidden features of the prompt. However, I had forgotten that I had removed battery status from my prompt, because I was depending on APM, which is no longer compiled in the kernel. A couple people have asked me since then why I’m depending on APM and not ACPI. I don’t have an answer, other than that was just what I coded. So, last night, I put up an ACPI implementation, and it works great. As with the APM implementation, if the battery percentage is less than 15%, the percentage display is red. If it’s less than 50% but greater than 14%, it’s yellow, and if it’s less than 100% but greater than 49%, it’s blue. If it’s 100%, or the tool “acpi” is not installed, then it doesn’t show up. Here’s a screenshot below:

While hanging out in our local LUG channel for the Ogden Area Linux Users Group, I got talking with Seth about prompts. He decided to change his, including adding the dog from Nethack randomly “moving” in the prompt. He also mentioned changing the color of the path if the present working directory was not writable. I really liked this idea, and decided to implement it in my prompt. Here’s a screenshot of that in action:

I change the path color to yellow if the present working directory is not writable, as it’s noticeable enough to catch your attention, but subtle enough to not get in the way, and be distracting.

As usual, if you want the source, here it is. Yes, it’s public domain, as mentioned in the code, so have at it.

7 Reasons Why I Have NOT Switched To Google Chrome From Firefox

2009-10-12T21:45:04-07:00

I just finished reading 7 Reasons Why I Switched to Google Chrome from Firefox. I found the article a bit on the fanboy side, and I’ll address each of his points here, while also saying my reasons why I’m still holding on to the Firefox browser as my default browser.

First, Andrew mentions that Google Chrome has a “much faster loading time”. I have Google Chrome installed on both my work laptop running Windows XP and two of my GNU/Linux machines, one running Ubuntu 9.04, the other running Debian Sid. In all three cases, Google Chrome does launch from cold boot noticeably faster than Firefox, but the daily web browsing is not so noticeable. Unless I’m benchmarking the two browsers side-by-side, which is really only good for showing benchmarks, I don’t see any recognizable differences in speed when rendering HTML, CSS or JavaScript. I’ve used both Chrome and Firefox with Gmail, Google Wave, and many, many other processor-intensive sites, and I see no such conclusion that Chrome has a “much faster loading time” versus Firefox, who is making the web a slow experience.

Second, he addresses that Chrome doesn’t crash. Funny you say that. I’ve had both the stable version running on Windows XP and the unstable version running on GNU/Linux tank very recently. It only happened once, in both operating systems, and I have not been able to reproduce it, but it wasn’t just a tab failure. The whole browser went south. I honestly don’t even know what happened, but I do know what I was doing, and what was lost, but I’ll address that in a second.

Thirdly, he likes some of the snazzy tab features with Chrome. It’s apparent though, that the features he addresses in Chrome also exist in vanilla Firefox 3.5, such as the ability close all tabs other than the open tab (right-click the open tab, select “Close other tabs”). I do wish Firefox would get closing tab order and tab placement correct though. It does bother me that when I open a link in a new tab, it doesn’t open the tab right next to the current, and when closing tabs, it doesn’t do so in oldest to most recent opened tab. However, that’s the beauty of Firefox- extensions, which again, I’ll cover in a minute.

Fourth, I do like the default home page in Chrome, and I wish Firefox had it. I’m hoping we’ll see it in 3.6 or maybe 4.0. However, it’s hardly anything new. As usual, Opera pioneered the feature, Safari followed suit, then Chrome. It is a leg up on Firefox, however.

Fifth, the Omnibar in Chrome is no different than the AwesomeBar in Firefox, except for the search functionality. But, seeing as though the search box in Firefox is just a tab keystroke away, I hardly find this inconvenient, and worthy of a reason for switching browsers. Further, it’s limited in its search scope- it can only search from one engine, Google by default. The search bar in Firefox is much more customizable, giving you the option to add virtually any search engine to the browser. Google, Wikipedia, eBay, Ubuntu packages, and so forth. Sure, you can change the default search in the options in Chrome, but you have to change the option by opening the options dialog every time you want to make the change, rather than just do it on the spot ad hoc.

The sixth option is just silly. Known more widely as “porn mode”, every major browser comes with this feature, even in Firefox 3.5. A mere “ctrl+shift+p” will put Firefox into “Private Browsing”, not saving an ounce of history to disk. Further, rather than opening a new window, it caches off your currently open tabs, closes them, and puts the new porn mode tab as the current tab, all in the same window. When you’re finished, stopping private browsing will restore your tabs from the saved cache, including any text you might have typed in any form field. Sorry, but this point I found rather silly.

The seventh point is likely just as silly. Firefox has had a bright future from the outset. It truly is the poster child for a grass roots open source project that becomes mainstream. Version 3.6 is looking up, and 4.0 has a bright future as well. According to the browser market share trends, Firefox has been up, up, up.

Now, here are seven reasons why I won’t be switching from Firefox to Google Chrome as my default browser in the foreseeable future:

Extensions- I know this is “in the works” for Google Chrome, but I can’t ditch Firefox just yet. I have a must set of extensions for every install of Firefox I ever make. I used to keep an updated list of such extensions, but I haven’t updated in a while. Maybe I should do so. But, on every install, I need AdBlock Plus, FoxyProxy, FireFTP, Firebug, Web Developer, Tab Mix Plus, Weave, NoScript and Flashblock, just to name a few. Again, I understand it’s only a matter of time with Chrome before extensions appear, and they will sand-boxed too, increasing the stability and security of the browser. However, Chrome isn’t there yet, and as such, Firefox remains my browser.
Caching- Firefox is the only browser that I know of that gets caching right. If, for any reason, my browser crashes, and I was typing an email, when I pull the browser back up, not only are my tabs restored, but the data in the tabs as well, including each tab history, and the text in any form fields that I was editing (provided I’m keeping a history of everything, as is default on a new install). I can’t even begin to tell you how valuable this feature is. Yes, the whole browser crashes with Firefox, versus single tabs with Chrome, but when Firefox comes up, my data is in tact. When I restore the tab with Chrome, form fields and text boxes that were once populated are now blank.
Cross Platform- Even though I have Google Chrome installed on my Debian and Ubuntu machines, Google Chrome is still very much a Windows application. It just hasn’t reached prime time for Mac OS X or GNU/Linux. So, unless I’m ready and willing to take the rolls with the punches, I’m stuck on Windows. Yes, Google Chrome is getting more and more usable every day on GNU/Linux, but it’s still unstable and comes with bugs.
Portable Firefox- Being a college student, I’ve come to love Portableapps.com. I can take so many applications with me on a USB stick, plug them into a Windows machine at school, and off I go. Firefox is no exception. I can have all my extensions, plugins, settings, bookmarks and so forth with me on a single USB stick. This way, I don’t have to worry about installing Firefox should it not be installed, and I don’t have to prep it installing and configuring it the way I like. So, until Chrome becomes a portable app as well, which I don’t think should take long, Firefox is here to stay.
Speed- Firefox is still a fast browser, and 3.6 is looking to up the ante even more. Tracemonkey is comparable to speed with V8 in terms of JavaScript engines, and HTML/CSS rendering is also snappy. In fact, I noticed a great improvement from 3.0 to 3.5 in terms of speed. And when browsing the sites I do from day-to-day with Firefox and Chrome, I honestly can’t tell if one is faster than the other. Yes, from a cold boot, Firefox is a second slower. Maybe two. Other than that, IMO, it’s neck and neck, and as a result, I see no reason to switch browsers if speed is a factor.
Configurability- Firefox is the only browser I know of that tinkering under the hood is a snap. Just pulling up the “about:config” URI, and I can tweak to my hearts content, and I have. I’ve modified the way DNS is handled. I’ve modified the way proxies are setup. I’ve changed the backspace key behavior, and much more, and it’s easy. Further, if I don’t like the setting I’ve made, I just change it back, all while it’s running in a tab in the browser. No need for open dialog windows, or taking you away from your work.
Support- This might seem like somewhat of a weak point, but Google Chrome has a bit to go before the community reaches the masses that Firefox has amassed. Support forms, IRC channels, wikis, mailing lists and on and on. If I need help with the Firefox browser, I’m likely to get the support I’m looking for, regardless of the platform. As Google Chrome increases it’s market share, there’s no doubt that it will increase it’s support options and community as well. However, it’s not there yet, and literally pales in comparison to Firefox. There is strength in numbers.

These may or may not be your reasons for sticking with Firefox, but they are certainly mine. Firefox is a solid browser that is showing tons, and tons of potential. While it might not have some bells and whistles that Chrome has, such as a process per tab, or sandboxing extensions, it’s still a robust and stable browser, and as a result, still remains my default browser.

WIFI FAIL

2009-09-09T06:28:48-07:00

While taking the bus home yesterday from work, I needed to login to work over the VPN and get some stuff done, before the next day started. The express bus I take home has free WIFI on the bus. Unfortunately, it’s anything but reliable or stable. I kept losing the connection, then I would have to reconnect, then it would drop, then reconnect, etc. While going through this, I noticed in the WIFI applet for Windows XP that it tells me I currently not connected, but if I wish to disconnect, I need to click the disconnect button. So which is it? Am I connected, or not? If I click the disconnect button, I guess it disconnects me, but when I click the button again to connect, it says again that I’m currently not connected, and if I wish to disconnect, click disconnect. Confusing as hell, I figure it’s loaded with FAIL, and that it would be fun to show.

Scrubbing Hard Disk Data

2009-08-31T18:52:26-07:00

I’ve recently had the opportunity with wiping 13 SCSI drives. The drives are small- 36 and 18 gigabyte drives, and they do contain sensitive data. They will be sent off to a third party for physical destruction, but we need to make sure that the data is completely overwritten on the disk in a secure manner. This means using a utility that can overwrite bit-for-bit on the disk level. Fortunately, there are many utilities for making this possible.

The most popular of these, is DBAN, or Darik’s Boot and Nuke. It comes as a CD or USB image that you boot from, rather than the disk, then choose in a menu which wiping method you wish to choose. Of the choices, there are:

Quick Erase- One pass, writing nothing but zeroes.
RCMP TSSIT OPS-II- Eight passes using random writes and compliments on each pass.
DoD Short- Three pass version of the stronger seven pass below. Each pass is random data written.
DoD 5220.22-M- Sever passes using random data at each pass.
Gutmann Wipe- 35 passes across the hard drive as described by security expert Peter Gutmann and Colin Plumb.
PRNG- Arbitrary number of passes specified by the user using a pseudo random number generator for writing random data on each pass.

For most secure scrubbing purposes, a quick erase is more than good enough. There have been no published papers to date on recovering overwritten date after a single pass. Is that to say it’s not possible? No, of course not. For what it’s worth, all the drives that leave my possession only get a single pass. However, if you or or organization is more paranoid about getting the data off the platters, there are other options available that will do more passes on the drive.

The next option in the DBAN menu is the RCMP TSSIT OPS-II wipe. This pass uses a source for a pseudo-random number generator as the first pass, then produces the compliment of that first pass as the data for the second. The idea behind this method is switch the bit on the disk platter from one to zero as often as possible. By using a random source for the initial pass, then writing the compliment, we’ve successfully written two passes on disk. At this point, it should be “good enough” for even the most seasoned data recovery company. However, this pass does that dance three more times, for a total of eight passes.

The Department of Defense, in the United States of America, has established a standard for sanitizing disks that contain TOP SECRET data. They have two standards. The first is the “DoD Short” wipe. This is a short three pass wipe. Nothing fancy about it. Each pass uses a pseudo-random number generator as the source for the overwriting data, and makes three passes with this source. The “DoD 5220.22-M” is the more secure DoD sanitization method, which uses seven passes across the disk instead of three. Each pass uses a pseudo-random number generator for the source of the data.

The next method is for the ultra-paranoid company or individual. This wipe is known as the “Gutmann Wipe”, and it’s built to take advantage of different hard disk encoding mechanisms. Essentially, there are two main encoding schemes for storing the data on your disk: MFM and RLL. All modern drives today use the RLL encoding scheme. Essentially, RLL is a lossless compression encoding scheme, making it possible to fit more data on the disk platters. Because MFM and RLL store data differently on the drive, using a certain method might be optimized for MFM encoded drives, but won’t work well with RLL and vice-versa.

The method behind calculating the data to the disk is rather simple: generate a unique list of one-bit numbers (zeros and ones), then two-bit numbers, then a three-bit numbers, then finally four-bit numbers uniquely. After this list of numbers has been generated, begin writing. This list is as defined in hexadecimal:

1-bit: 0×000, 0xFFF
2-bit: 0×555, 0xAAA
3-bit: 0×249, 0×492, 0×942, 0×6DB, 0xB6D, 0xDB6
4-bit: 0×111, 0×222, 0×333, 0×444, 0×666, 0×777, 0×888, 0×999, 0xBBB, 0xCCC, 0xDDD, 0xEEE

If you want to convert this list to binary, then think about it in terms of the “number of bits”. For example, with one bit, you only have two options: a zero or a one. With two bits, you have a possible combination of 4 numbers: all zeroes, all ones, zero then one or one then zero. Because we’ve already defined “all zeroes” and “all ones” in the one-bit number, we don’t need to repeat them in the 2-bit, 3-bit or 4-bit representation. Now, why repeating that bit 3 times? Well, the least common denominator of three and four is twelve. The idea is that I’m writing patterns, not necessarily static data. So, the pattern needs to repeat through the 12-bit number. For example, take the 4-bit number

0x999

What is this in a 12-bit binary representation? Isn’t it:

100110011001

or if you were to separate it out:

1001 1001 1001

Do you see the pattern of two ones followed by two zeroes, followed by two ones followed by two zeroes, etc? That’s the idea. Writing patterns to the disk.

So, how do we put all these numbers together, so we can sanitize the data securely for both RLL and MFM drives? Wikipedia has a good article on it, and explains that the first and last four writes are random data from a secure random number generator. Then, at pass five through pass 31, we use the 1-bit through 4-bit numbers we came up with, and begin writing, some of them used two or three times, based on the drive encoding scheme it’s targeting.

Lastly, if this isn’t enough, you have one last option, where you can specify the number of passes for wiping the data. The pseudo-random number generator that is used for the other passes is chosen here, and each pass writes random data to the disk.

This is a great utility for sanitizing disks, however, I’ve found DBAN to be spotty on certain hardware configurations. For one, it’s x86-based only, which means you won’t be able to boot this on Sparc or HPPA-RISC hardware. Also, even on some x86-based hardware, I’ve found DBAN to hardlock, not ever getting to the menu for me to begin wiping. So, what can I do? Am I up a creek without a paddle? Most definitely not!

KNOPPIX is a solid LiveCD that loads the Linux kernel and the Debian user-space utilities, giving you a live desktop, complete with all the tools you would need for rescuing and wiping machines. KNOPPIX has been soundly tested against a vast array of hardware, and it sees very active development with a vibrant community behind it. How can KNOPPIX securely delete the data off your drives? Well, GNU Shred from the GNU Coreutils package is a flexible package for choosing the number of passes against a drive. Because you’ve booted into a live Linux environment, you also have /dev/zero, /dev/random and /dev/urandom as a source of endless data for sending to your drives. In my specific situation of wiping the 13 SCSI drives, I booted into a KNOPPIX CD, executed ’shred’ and told it to do three passes, then one last pass of zeroes, hiding any evidence of data sanitization. Many other GNU/Linux distributions provide live environments (CD or USB) that you could take advantage of. Ubuntu, openSUSE, Debian and Fedora are just a few worth mentioning.

Of course, if you’re running an encrypted filesystem worth its salt, then there really is no practical reason for scrubbing the data off your drives, and the encrypted representation of your data doesn’t mean squat without the private key to that data.

Moving to Movable Type

2009-08-21T23:00:58-07:00

After weighing in the pros and cons, it looks like I’ll be migrating my blog, and all of it’s data to a Movable Type install, rather than a Wordpress install? Why? I’m hoping to take some strain off the server by removing the database on the posts.

Honestly, I don’t know why blog engines have databases for posts, when static HTML files can be produced rather effortlessly. I understand WP Cache does something similar, but I’ve had mixed results with that plugin.

Anyway, the blog migration will probably happen sometime this weekend, ready for a new life Monday. Also, I’m hoping that I can preserve date timestamps in the RSS feed, so as to not spam the planets that I currently push to. I’ll be testing in a development environment first, to make sure everything goes smooth, not like you care.

See you on the other side.

Mobile LVM

2009-08-16T02:16:56-07:00

Today, as my wife and I were headed into Target, I thought of the cheap USB thumb drives they usually have on sale, and I was tempted to purchase some. Then I got to thinking: what if I could use those thumb drives as one disk, using LVM, and have the ability to take that LVM structure from computer to computer? For example, say I have 6 2GB USB thumb drives. I have 12GB of storage total. Maybe I want to fit a DVD ISO or two on the disks. LVM would be perfect for this, if it remains on one computer. Wouldn’t it be nice if I could take those 6 drives to another computer, scan for the LVs, and mount them, keeping all my data in perfect order? Well, after a bit of hacking about, I figured it out, and it’s cleaner than you would think.

I’m not going to bother teaching you about the concepts behind LVM here. Suffice it to say, that LVM provides complete flexibility and control over your disk pools, where editing and manipulating partitions would be troublesome. The idea behind LVM is to create a pool of disk space, whether it comes from one drive, or many, and have the ability to chop up that pool to create mount points easily, as well as resizing the volumes, either larger or smaller.

So, to get started, let’s keep it simple. I have two 32MB USB thumb drives with me right now for this post. When I plug them into my computer, my Linux kernel might recognize them as /dev/sdy and /dev/sdz, for example. You can find these results by running “fdisk -l” as root, checking the end of the dmesg command, or checking the end of /var/log/messages.

If they have a filesystem on them, and your desktop mounts them automatically, like GNOME or KDE will traditionally do, then you’ll need to unmount the devices. Once unmounted, we’ll need to partition the devices, and label the partitions as “Linux LVM”. I’ll leave that step up to you. Some good utilities of making this happen are fdisk, sfdisk or parted. You will only need one partition on each drive. Make sure the partition covers the whole disk, and make sure the partition is labeled as “Linux LVM”. If the partition is not labeled appropriately, it could cause problems for you later down the road.

Now that you have your disks partitioned, and labeled correctly, let’s start building the LVM structure. This is done by creating physical volumes first, then adding them to a disk pool, and chopping up the disk pool as needed for our mount points. Caution: This next step will erase any filesystem, and as a result, any data on the drives.

Pull up a terminal, type as root, and pay attention to the output:

# pvcreate /dev/sd{y,z}1
  Physical volume "/dev/sdy1" successfully created
  Physical volume "/dev/sdz1" successfully created

Now, time to add these two physical volumes to a drive pool. This next step is important, because you will give a name to the volume group. This name must be unique! Reason being: if you take this LVM structure to another computer, and it already has LVM implemented with a volume group that has the same name as yours, you’ll run into snags. So, for me, I used my GnuPG keyID. I figure that will be unique enough, that I shouldn’t encounter it on any computers I plan on using this with. But, you can name it whatever you want. Name it something that is useful to you. Of course, name it something very unique.

So, continuing in your terminal, type as root and watch the output:

# vgcreate 8086060F /dev/sd{y,z}1
  Volume group "8086060F" successfully created

Cool, at this point, I have about 64MB of space that I can chop up any way I see fit. Maybe I want a 50MB volume and a 14MB volume. Maybe I want one massive 64MB volume. Maybe I want 64 1MB volumes. The point is, you decide. When I create my logical volumes, I’ll be using the “lvcreate” command, which is rather detailed, so spending some time in the man pages will be of value.

Before continuing, we need to find out exactly how much space I have in my pool. LVM is keeping some metadata on the disks, so I will be losing some space. But how much? This is important to know when I start creating my logical volumes. I can get this data by running the “vgdisplay 8086060F” command:

# vgdisplay 8086060F
  --- Volume group ---
  VG Name               8086060F
  System ID
  Format                lvm2
  Metadata Areas        2
  Metadata Sequence No  1
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                0
  Open LV               0
  Max PV                0
  Cur PV                2
  Act PV                2
  VG Size               52.00 MB
  PE Size               4.00 MB
  Total PE              13
  Alloc PE / Size       0 / 0
  Free  PE / Size       13 / 52.00 MB
  VG UUID               F0pWrc-030s-03Uo-SoLl-7Tvf-ZETc-3hcxfG

“Free PE/Size” is what we’re looking at. In this case, LVM is using 12MB of metadata stored on the disks for its operations. If each extent is 4MB and I have 52MB of space, then that means I have 13 physical extents that I can use. This is the “PE” number. So, I’m going to use that number when creating my logical volume. I’m also going to name it something personal; something that has some meaning to me. Because this will be holding my personal data, I’ll name it “personal”.

Pull up a terminal, and as root:

# lvcreate -n personal -l 13 8086060F
  Logical volume "personal" created

Sweet! I have a logical volume that I can now put a filesystem on, mount, and start moving data to. So, let’s get to it:

# mke2fs -j /dev/8086060F/personal
... [Output snipped] ..
This filesystem will be automatically checked every 34 mounts or
180 days, whichever comes first.  Use tune2fs -c or -i to override.

Next, let’s mount it:

# mount /dev/8086060F/personal /mnt
# echo "Testing file on LVM" > /mnt/file.txt

We now at this point have our LVM structure created, formated, mounted and data on it. Now, the key is to take these thumb drives out of the computer, take them to a separate computer, and rebuild the exact LVM structure keeping the data in tact. After all, that’s what we’re after, right? Mobile LVM?

Unmount the device:

# umount /mnt

If you get an error here, run fuser, with its various options, to find why the umount is failing.

Now with the logical volume unmounted, we need to deactivate it. This effectively takes the volume offline, so it can’t be accessed for data retrieval or storage. This can be handled with the “lvchange” command. Looking at the man page, in order to activate or deactivate a logical volume, you need to pass the “-a” switch. “-a y” would activate it, and “-a n” would deactivate it.

In your terminal:

# lvchange -a n /dev/8086060F/personal

No output will be there, but the device “/dev/8086060F/personal” should no longer exist. Now, we need to do the same thing with the volume group, telling LVM that we are finished with this group, and we no longer need its data. Surprise, surprise, this is done with the “vgchange” command, and we pass the same switch with its argument:

# vgchange -a n 8086060F
  0 logical volume(s) in volume group "8086060F" now active

At this point, it is safe to unplug the drives from your computer, and plug them into the new computer.

It’s typically best practice to notice how the Linux kernel identifies the drives when plugging them into a new machine. Knowing this information won’t necessarily be of vital importance to us during this tutorial, but it could be of importance when troubleshooting. Let’s say the kernel recognized the drives as /dev/sdk and /dev/sdl.

At any event, we need to have LVM2 and Ext3 installed on this new machine, if they aren’t already. Once those are installed, all we need to do is run pvscan to search the system for any new physical volumes. It should find our newly plugged in thumb drives, with all their metadata:

# pvscan
  PV /dev/sdk1   VG 8086060F   lvm2 [24.00 MB / 0    free]
  PV /dev/sdl1   VG 8086060F   lvm2 [28.00 MB / 0    free]
  Total: 2 [52.00 MB] / in use: 2 [52.00 MB] / in no VG: 0 [0   ]

Cool. It found them, and it’s telling me that they belong to a volume group called “8086060F”. If this volume group already exists on the new computer, LVM will let me know. This is why we needed to create a new volume group that had a very unique name.

All that’s left, is to activate the volume group, then activate the logical volumes, and I should be able to mount the volume, and access the data. Let’s give it a try:

# vgchange -a y 8086060F
  1 logical volume(s) in volume group "8086060F" now active

Sweet! So far so good. Notice too that I passed “-a y” to activate the group, where previously, I passed “-a n” to deactivate it. Now the logical volume:

# lvchange -a y /dev/8086060F/personal

No output, but can I mount it and access the data?

# mount /dev/8086060F /mnt
# cat /mnt/file.txt
Testing file on LVM

YES! WE DID IT! We’ve rebuilt the LVM structure on a completely different computer, and our data remained untouched. At this point, I can modify, add, remove data on the LVM to my hearts content. When I’m finished, as you’re already aware, I can unmount the volume, deactivate the LV, deactivate the VG and remove the drives for the next computer.

This process, as you have figured out, has quite a few steps to it, and it requires some knowledge about how LVM works. However, this pays off, I think, and it’s rather straight forward.

Not all is peaches and cream. You might have made a mistake during the process. Maybe you pulled out the drives before deactivating, and when you get to the new computer, it won’t build the LVM structure, or something equally as troublesome. LVM keeps a cache on all it’s operations in “/etc/lvm/cache/.cache”. You can safely remove this file, if it gets in your way. LVM will recreate it as necessary. That might fix your problem, it might not, but it’s worth pointing out.

I currently have 10 USB thumb drives, each of differing sizes as well as 3 mobile external hard disks. I’ve got roughly 200GB of raw storage at my disposal. With just flat filesystems, I can’t put down a 100GB file, unless I have a drive large enough to support it. The largest drive in my collection is a mere 80GB, so LVM fits the bill perfectly in making this possible, by combining all the disks. And because I can tear it down and rebuild it regardless of the computer I’m sitting at, as long as LVM2 and the Ext3 filesystem are supported, I can access the data.

Of course, you can choose any filesystem you want here. Just remember, however, that XFS does not support shrinking the filesystem. But, it’s your drives, so do what you want.

Further, if you really wanted to have fun, because you have multiple disks, you could totally take advantage of Linux software RAID. Because the structure we outlined above doesn’t cover redundancy, if you lose a disk, your data could be corrupted. So, RAID would make sense, however, it complicates the mobility, by making sure Linux software RAID is also installed on the target machine, and it adds an extra step to activating the drives by rebuilding the RAID array first THEN rebuilding the LVs. And of course, if you’re paranoid, you could add encryption on top of it with cryptesetup and LUKS. Again, though, another step getting to your data when tearing down and rebuilding. All thoughts for another post.

I don’t care what you say, this is just too cool for school.

The Official Root Certified, LLC Launch!

2009-08-11T21:34:11-07:00

Today is a big day. Christer Edwards and I have gone into business with each other starting a Linux and Unix company here in Utah. We’re named “Root Certified, LLC”. We specialize in Linux hosting, Linux and Unix consulting and auditing. You can find more about us at our page: http://rootcertified.com.

If your company is looking for consulting or auditing in security, backups, virtualization, network services, troubleshooting or virtually anything else Linux or Unix reliated, we are the company for you! We can help you achieve industry standards, tighten your physical and network security, setup and configure all sorts of services and more. Further, we offer fully managed Linux hosting for your company or organization. You give us the data, and we do the rest. We have different packages for different needs, and our packages are completely flexible.

And we’re not stopping there! This is just the tip of the iceberg. We have some exciting new corporate expansions that we’ll be working on in the near future that will engage the Free Software and Open Source communities, bring additional education to the masses, and overall increase Linux and Unix adoption in both the server and desktop markets.

We’re excited for what we can do for you. Contact us here to see how we can meet your needs.

It’s That Time Again

2009-06-09T05:12:55-07:00

1	echo 'by9+IEhhcHB5IEJpcnRoZGF5IHRvIHlvdSEgSGFwcHkgQmlydGhkYXkgdG8geW91ISBZb3UgbG9vayBsaWtlIGEgbW9ua2V5LCBhbmQgeW91IGNvZGUgbGlrZSBvbmUgdG9vISBvL34K' \| base64 -d

GnuPG Up And Close

2009-06-08T23:09:15-07:00

Every GNU/Linux distribution ships with GnuPG by default. While they all don’t ship with the same GUI frontend, they do ship with the the same CLI backend. So, we’ll be interfacing with that throughout this informational session. I’m not presenting this as anything necessarily useful. Rather, I hope you find it informational/educational, and learn a little bit with how GnuPG works “under the hood”. So, let’s have some fun. First, a list of the “standard” algorithms that ship with GnuPG on a GNU/Linux system. This is completely based on the type of main public and private keys as well as any subkeys that you’ve generated. You can see a list of supported cipher, digest and compression algorithms by invoking the gpg binary and passing “–version” as an option. For example, here is the output from my Debian GNU/Linux unstable laptop:

$ gpg -v --version
gpg (GnuPG) 1.4.9
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Home: ~/.gnupg
Supported algorithms:
Pubkey: RSA, RSA-E, RSA-S, ELG-E, DSA
Cipher: 3DES (S2), CAST5 (S3), BLOWFISH (S4), AES (S7), AES192 (S8),
        AES256 (S9), TWOFISH (S10)
Hash: MD5 (H1), SHA1 (H2), RIPEMD160 (H3), SHA256 (H8), SHA384 (H9),
      SHA512 (H10), SHA224 (H11)
Compression: Uncompressed (Z0), ZIP (Z1), ZLIB (Z2), BZIP2 (Z3)

So, for ciphers, I support 3DES, CAST5, BLOWFISH, AES, AES192, AES256 and BLOWFISH. For digest hashes, I support MD5, SHA1, RIPEMD160, SHA224, SHA256, SHA384 and SHA512. Lastly, for compression algorithms, I support uncompressed, ZIP, ZLIB and BZIP2. Your output my vary slightly one way or the other. For example, you may not see the full suite of SHA algorithms. This can be obtained by generating an RSA subkey for signing only. Other ciphers might include IDEA, CAMELLIA128, CAMELLIA192 and CAMELLIA256, and you could have TIGER and WHIRLPOOL as possible supported hashes.

With all these algorithms, how do you know which to use and when? Fortunately, GnuPG takes care of that for you automatically. However, you can tell it what you would to prefer to use for each, if you like. You can set these in your ~/.gnupg/gpg.conf file. The options you are looking to set are “default-preference-list”, “personal-cipher-preferences”, “personal-digest-preferences” and “personal-compress-preferences”. For myself, here is what I have set in my gpg.conf:

default-preference-list 3DES CAST5 BLOWFISH AES AES192 AES256 TWOFISH MD5 SHA1 RIPEMD160 SHA224 SHA256 SHA384 SHA512 Uncompressed ZIP ZLIB BZIP2
personal-cipher-preferences TWOFISH AES256 AES192 AES BLOWFISH CAST5 3DES
personal-digest-preferences SHA512 SHA384 SHA256 SHA224 SHA1 RIPEMD160 MD5
personal-compress-preferences BZIP2 ZLIB ZIP Uncompressed

Now, when we printed out the verbose version, we saw in parenthesis S2, S3, H8, H9, Z1, Z2 and so on. We can use these instead of the name in our gpg.conf if we so wish. I prefer the name, as I can’t recall the key to the algorithm, and it’s easier to read. So, in my case, I list out everything that I want for a default list of preferences, then I choose the order of which to pick from when encrypting, signing and compressing. So, for encryption, I have set TWOFISH as my first choice, with AES256 as my second choice, then AES192 as my third, and so forth. I’ve done the same with my preferred digest hashing algorithm choosing SHA512 first, then SHA384 second, and so on, and the same with compression.

Why set the preference? For starters, if you’re like me, you sign all your email by default. You probably want your signature to withstand the test of time as long as possible. Given the strength of today’s hardware, why not choose the strongest encryption and hash algorithms? But on a more practical note, if you’re encrypting data to yourself, this would tell GnuPG to use TWOFISH as the encryption algorithm. This means that if you want to decrypt it at a later date, maybe on another computer, you’ll need to make sure TWOFISH is compiled into GnuPG. How would you know what was used? We’ll cover that in a bit.

However, what about encrypting to someone else other than yourself? How do these preferences come into play? Well, you can also set preferences in your public key. The purpose of this, is when people grab a copy of your key, and they want to encrypt something to you, GnuPG will negotiate the first preferred algorithm that is common between the two end points (the one doing the encrypting and the one receiving the encrypted data).

For example, let’s suppose Alice has a GnuPG keypair as does Bob. In Alice’s public key, which Bob has a legitimate copy of, she has set a cipher preference order of: TWOFISH BLOWFISH AES CAST5 and 3DES. Bob wants to encrypt data to Alice. Because he has a copy of her public key, he can do this. The question here is, which algorithm will be chosen for the encryption? Well, Alice prefers TWOFISH as a first pick. If Bob has compiled TWOFISH support in his copy of GnuPG, then it will be used. Suppose he doesn’t have TWOFISH support. Then the next preferred algorithm is BLOWFISH, because it’s Alice’s second pick. Let’s say Bob does support it, then BLOWFISH is the algorithm used for encrypting the data to Alice. When Alice receives the encrypted data, she’ll use the BLOWFISH algorithm along with her private key to decrypt the data. Should she wish to reply, her copy of GnuPG will pull out the preferences from Bob’s public key, and go through the same process looking for the first preferred algorithm by Bob that is supported by both parties. The “SSL handshake” works much in this same manner.

Digest hashing works much the same way, but slightly different. Because the recipient doesn’t matter with signed data, then rather than looking to public keys for the digest algorithm preference, you turn to your gpg.conf file, if listed, and use that there. If the recipient, or recipients have a copy of your public key, and the same digest algorithm compiled into their copy of GnuPG, they can verify your signature. If either is missing, the public key, or the algorithm, the signature will fail, and GnuPG will explain the problem. This process is the same for compression algorithms.

So, we’ve made the preferences in our gpg.conf, but how do we set them in the public key, so we can distribute this to others? Well, in this case, we need to edit our key. From the terminal (I’ve snipped out the noise, focusing only on what’s important):

$ gpg --edit-key KEYID
gpg (GnuPG) 1.4.9; Copyright (C) 2008 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Secret key is available.
[ ... SNIP ... ]

Command>

We are now sitting at a command prompt that we can use to pass commands in an interactive fashion. I should mention that all this can be done non-interactively. Checking out the gpg manual will provide the list of options for making this possible. Typing “help” will give us the list of commands that we can pass:

Command> help
[... SNIP ...]
pref        list preferences (expert)
showpref    list preferences (verbose)
setpref     set preference list for the selected user IDs
[... SNIP ...]

The commands that we are interested in “pref” and “setpref”. Passing “pref” might give us something like the following:

Command> pref
[ultimate] (1). Aaron <aaron@example.com>
     S10 S9 S8 S7 S4 S3 S2 H10 H9 H8 H11 H2 H3 H1 Z3 Z2 Z1 Z0 [mdc] [no-ks-modify]

See those algorithm codes we saw at the beginning of this tutorial? They are listed in the preferred order that we wish to have each algorithm. In my case, I have all my encryption algorithms lists, from strong to weak, then hashing from strong to weak, then compression from most tight to no compression. What if I wanted to set a different order, or maybe not include some preferences: Using “setpref” makes this possible:

Command> setpref S10 S9 S8 S7 H10 H9 H8 H2 H3 Z2 Z1 Z3 Z0
Set preference list to:
     Cipher: TWOFISH, AES256, AES192, AES, 3DES
     Digest: SHA512, SHA384, SHA256, SHA1, RIPEMD160
     Compression: ZLIB, ZIP, BZIP2, Uncompressed
     Features: MDC, Keyserver no-modify
Really update the preferences? (y/N)

Typing “y” will of course make the setting in your key. At this point, you’ll be asked to enter your private key passphrase successfully before continuing. At that point, it will be statically set in your public key, and you can send your key off to the keyservers and emailed to your family and friends, so they can immediately start taking advantage of the new preferences. Type “quit” to leave the prompt.

Now, let’s say you have some signed and encrypted data, and you’re curious of the algorithms used when creating the cipher text. This can be done by passing the “–list-packets” option to gpg to see the data packets. We’ll need to turn on verbosity as well. For example, the output of a file I sent to a friend using the Mutt email client (emphasis mine):

gpg -v --list-packets file.txt
gpg: armor header: Version: GnuPG v2.0.11 (GNU/Linux)
[... SNIP ...]
gpg: AES256 encrypted data
:compressed packet: algo=3
:onepass_sig packet: keyid CE7911B7FC04088F
	version 3, sigclass 0x01, digest 8, pubkey 1, last=1
:literal data packet:
	mode t (74), created 1244484492, name="mutt-helios-1000-24974-13",
	raw data: unknown length

Here, I can easily see that AES256 was used for the encryption algorithm, but what’s this compressed “algo=3″ and “onepass_sig packet digest 8″ stuff? Well, in order to understand those, we need to turn to RFC 4880. This RFC describes the OpenPGP message format and the standards used. Browse your way down to section 9, and you’ll see what “algo=3″ means for compression and “digest 8″ is for signatures. It appears, according to that RFC, that BZIP2 was used for compression and SHA256 was used for the hashing algorithm. So, in this case, Christer and myself preferred those settings higher than the others, and my GnuPG acknowledged those preferences and did the encrypting, signing and compressing as told. We can see these by “editing” his key:

$ gpg --edit-key christer
[... SNIP ...]
Command> pref
[  full  ] (1). Christer <christer@example.com>
     S9 S8 S7 S3 S2 H2 H8 H3 Z2 Z3 Z1 [mdc] [no-ks-modify]
[... SNIP ...]

Command> quit

Christer places AES256 has his first preferred encryption algorithm. Because I also support this algorithm, this is used for the encryption. SHA1 is his preferred digest hashing algorithm with SHA256 as his second preferred, but remember that for the signature and compression, these preferences are found in my gpg.conf instead. I prefer SHA512 as my first preference, but he doesn’t list it as suported (according to his public key), so I move down to SHA384. Again, he doesn’t list it, so I try SHA256. He lists it, so it’s used. Lastly, BZIP2 as the compression algorithm, and he lists it, thus it’s chosen. Thus, the results we got. Make sense?

I hope this has been informative. It’s been great discovering the details of how these algorithms were chosen, and it’s been fun playing with all sorts of encrypted emails and files to get to the guts of the GunPG process. If I’ve misrepresented any data here, or you have questions, please let me know.

Password Policies Suck

2009-05-28T15:06:40-07:00

I’ve been getting a flurry of emails at work, reminding me that my passwords are about to expire on several Unix and Linux machines in our production datacenter. They have a policy in place, where the password much be changed every 90 days, and I have to keep my current password for at least 7 before changing it, and I can’t use any password that has been used previously, let alone, the insane requirements for the password. So, rather than fight it, I thought I would make this easy on myself.

First, I’m a big fan of SSH key authentication. Because I’m allowed to use SSH authentication, I have my public SSH key on all the servers in the datacenter. When my password is about to expire, I get an email notice once per day two weeks in advance. I can use this email as an opportunity to execute a script that will change all the passwords on all the servers for me. In the script, I’ll have it grab some data from /dev/urandom, and create a sha1sum of the input. An encrypted version of the hash will then be saved locally to disk, which will be encrypted with my GnuPG key, and emailed to myself, should I need the password for something other than SSH. Lastly, just so the password can’t be compromised, only the encrypted versions of the password remain on disk. The hashes themselves are shell variables that are cleared when the script exits. Further, I’ve changed the permissions on my home directory, where my SSH keys and GnuPG keys exist, such that everything sensitive is only accessible to myself. I realize that convenience comes at the sacrifice of a bit of security. My laptop is running full disk encryption, and my password to guard my account is strong. I am the only one on my machine, and I expect it to stay that way. As such, I’m not worried about anything getting compromised.

All of this is stored in a simple shell script, shown below. You will need the “expect” and “sha1sum” packages installed on your system before executing this script. You will need a GnuPG key pair generated for encrypting and decrypting data. You’ll need SSH keys created and distributed to each server beforehand. You should probably have your SSH keys added to your SSH agent, as well as your GnuPG key added to a GPG agent before executing the script, to save you some serious typing. I won’t cover that here, but Seahorse is a great utility for managing GPG and SSH keys. Of course, your SSH keys and GPG keys should be passphrase protected.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

#!/bin/sh
# License: public domain
if [[ -f newpass.gpg ]]; then
mv -f newpass.gpg oldpass.gpg
OLDPASSWD="$(gpg -d oldpass.gpg)"
fi

# Change "Your Name" to fit the user ID that matches in your GPG key
dd if=/dev/urandom count=100 2> /dev/null | sha1sum -b - | \
gpg -ar "Your Name" -e - > newpass.gpg
# Change "username@domain.tld" to match the email you wish to send this to
cat newpass.gpg | mail -s "Password for servers" username@domain.tld

NEWPASSWD="$(gpg -d newpass.gpg)"

# Change "server1 server2 sever3" to match the hostnames of the servers you'll loop over
# Change "domain.tld" to match the FQDN for your servers
for host in server1 server2 server3; do
EXPECT=$(expect -c "
spawn ssh $host.domain.tld
send \"passwd\r\"
expect \"(current) UNIX password: \"
send \"$OLDPASSWD\r\"
expect \"New UNIX password: \"
send \"$NEWPASSWD\r\"
expect \"Retype new password: \"
send \"$NEWPASSWD\r\"
")
echo $EXPECT
done

Initially, when I started writing this script, I wanted it to run in cron locally on my laptop. As I began building the script, I realized this wasn’t a secure move, for a couple of reasons. First, as already mentioned, I’m using SSH authentication using public key cryptography. All of my SSH keys are passphrase protected. I didn’t want to store the passphrase in the script, so I could automate the process, and I didn’t want to remove the passphrase or generate new keys that didn’t have a passphrase. Further, wanting to encrypt the data, and send it to myself via email required that I store my GnuPG passphrase on disk as well. I didn’t like this idea either, as I’m already storing the new and old encrypted passwords on disk from the script, and that’s enough. No need to compromise security any further. So, I’ll run this script by hand.

However, we have a problem. You will be typing passphrases galore in this script if you have a decent number of hosts to loop through. So, as mentioned, it would probably be best to take advantage of an SSH and GPG agent to cache your passphrases to ease the pain before executing the script.

Looking over the script a bit. First thing to note, is it is sending the same password to every server. You might not want this. If so, feel free to modify the script to fit your needs. Second, the sha1sum hash is never stored on disk. Rather, it’s just stored in variables OLDPASS and NEWPASS. The idea between the old passwords and the new passwords, is so we can provide the current password when updating, as well as the old.

We’re pulling from /dev/urandom as a source for semi-random data. Yes, you can pull from /dev/random if it makes you sleep better at night. Also, we’re not pulling a lot of data, because ultimately, the SHA1 hash will be strong enough as it is. You’ll notice too that because we’re using STDIN for our data source, the hash contains a space, asterisk and hyphen following the hash, and we’re keeping it. I figured no reason to remove it, as spaces, asterisks and hyphens are valid UNIX password characters. If your company has a more draconian password policy than mine does, requiring specifically more than say 3 or 5 non-alphanumeric characters, then just append those to the end of hash before encrypting to disk. Maybe something like the string “!@#$%”.

Lastly, we’re emailing the encrypted password to ourselves, so no worries about compromising there, plus that gives us an extra backup in case we lose our disk that is storing the encrypted passwords. This also gives flexibility to where we can retrieve the password, provided we have access to the Internet and our GPG keys. Then we’re using “expect” to send the passwd command to the server and send our old and new passwords as prompted for each server. You might need to change the expected prompt depending on your GNU/Linux or Unix derivative (“New RedHat password: ” for example).

That’s it! Simple enough. If you have any questions, or improvements, please post them in the comments. Thanks!