~chuck/blog

UPDATE 081205: Adding “AllowTcpForwarding” to the sshd_config and restarting SSH should enable port forwarding, as it is disabled by default.

–

I have installed OpenSolaris on my Gateway MT3705 notebook.  I know.  I must be a glutton for punishment.

I have a Dell desktop that I also use, and like to have my laptop be the “control center”.  I accomplish this by using Synergy through an SSH tunnel.  Today was the first time I tried to use OpenSolaris as the host for my Synergy setup.  And it failed miserably.

After some googling, I found out that the SSH package in OpenSolaris is broken.  It doesn’t allow for correct SSH tunneling.  Here are some links for reference.

I run Debian on my desktop machine at present.  I’ve run SSH tunnels between my laptop and desktop while both were running Debian.  No problem.  I’ve set up an alias in my .bashrc on each of my boxes so that I don’t have to type the whole command each time:

alias synsetup=’ssh -f -N -L 24800:host:24800 host && synergyc localhost’

Obviously, this assumes that the host and client are already correctly configured.  I’ve discussed this previously.

So, I compiled and configured synergy in OpenSolaris, and tried to run the synergys command: No problem.  It runs fine, and works great on it’s own, outside of an SSH tunnel.  I can connect from the client without issue:

$ ps -ef | grep synergys
chuck  1159     1   0 19:44:13 ?           0:00 synergys

$ netstat -an | grep 24800
*.24800              *.*                0      0 49152      0 LISTEN
10.6.101.176.24800   10.6.101.174.38334    9088      0 49232      0 ESTABLISHED

But, running Synergy all alone transmits information between the two host over the network in plain text.  So, it’s best to run Synergy through an SSH tunnel.

Here’s a smattering of what I get when I follow the instructions from Synergy’s site on setting up the client through an SSH tunnel:

$ synergyc -f localhost
INFO: synergyc.cpp,716: Synergy client 1.3.1 on Linux 2.6.26-1-686 #1 SMP Thu Oct 9 15:18:09 UTC 2008 i686
DEBUG: CXWindowsScreen.cpp,841: XOpenDisplay(“:0.0″)
DEBUG: CXWindowsScreenSaver.cpp,339: xscreensaver window: 0×00000000
DEBUG: CXWindowsScreen.cpp,111: screen shape: 0,0 2560×1024 (xinerama)
DEBUG: CXWindowsScreen.cpp,112: window is 0×03400004
DEBUG: CScreen.cpp,38: opened display
NOTE: synergyc.cpp,330: started client
channel 2: open failed: administratively prohibited: open failed
NOTE: synergyc.cpp,276: disconnected from server
. . . (until Ctrl-C)
^CDEBUG: CScreen.cpp,49: closed display
NOTE: synergyc.cpp,408: stopped client

So, I googled the error message.  The first link shed some light. I dug farther, and found the links I posted above.

So, tunneling is broke on OpenSolaris, but works fine on Debian.  Why not reverse it? I set up this alias on my OpenSolaris laptop, to start the Synergy server.  It creates a reverse tunnel to the desktop machine, which runs Debian:

synserver_setup=’/usr/local/bin/synergys && ssh -f -N -R 24800:localhost:24800 chuck@client’

The only thing that’s different is the direction from which the tunnel is created.  To tunnel from the client to the server from the client, the ‘-L’ flag is used to create the local tunnel.  To tunnel from the client to the server from the server, the ‘-R’ flag is used to create the remote tunnel.  All set.

/cs

I have a few low-level development projects I want to undertake, and am working on building up my skills in systems programming. So, what better OS to use for a base than Linux, right? However, the Linux kernel is substantially large, and right now, I need to focus on trying to learn fundamental OS programming skills. I think it would be better to start with a smaller base system. Since Linux was written in and based on Minix, I figure I’ll give that a go. Here’s a short walk-through on installing the system in VirtualBox on a Debian Lenny host. Enjoy!

I assume that you already have a VirtualBox installation on your system and you know how to use it. I chose to use the 2.0.4 release of Minix, because the OS base grew substantially for version 3. You can download Minix 2.0.4 from here.

To start, create the VirtualBox guest. I called it, creatively, “Minix 2.0.4″. You can call yours what you like. I created a new virtual disk of 512M, which is much more than is necessary to install Minix, but will give me plenty of room to dick around.

Before booting, configure your Minix VM to boot from a floppy image. Navigate to the directory created when you extracted the Minix tarball, then to the i386 folder therein. You’ll see that there is nothing there. Tell VirtualBox to look for all files, rather than .IMG files. You’ll see the ROOT.MNX and USR.MNX files in your directory. For boot, we need to select the ROOT.MNX file.

Boot the machine. Press =, as it says, to start Minix. You’ll be prompted for a location of a device to use for mounting /usr. Unmount the floppy, as the root floppy is now loaded into RAM, by clicking Devices->Unmount Floppy on the VirtualBox window. Select Devices->Mount Floppy->Floppy Image… and navigate to the USR.MNX file we saw before. In Minix, finish the line with fd0 so that the device listed is /dev/fd0. Hit return, and you should be prompted with a login message. Above this, Minix explains that to install, you need to issue the setup command. Ignore this. We’re going to use the included documentation, and do things manually. What a concept!

In the extracted folder from the Minix tarball, you’ll find a file called usage.txt. This file contains both “automatic” and “manual” installation instructions for Minix. Open the file in your favorite editor. I use vi.

Scroll down to section 6. MANUAL INSTALLATION. These are the instructions we will use to install Minix. Sort of.

First things first, type root at the login prompt to log in as the root user.

Now, issue the part command to start the disk partitioner. For help in part, type ?. I scrolled using the arrow keys to the Kb column, and typed in the entire disk size, since we are not going to partition a VM. How silly would that be? Type the > key on the newly created partition to create the “subpartition” scheme. This is much like partitions inside a FreeBSD slice, except Minix refers to them as slices inside a partition It’s all semantics. I created partitions as follows:

Size in K Partition Description
1440 My Root partition, to be mounted as /.
10240 Partition to mount at /usr.
2880 Swap.

This creates just under 15M of partition space for use on the Minix system, and leaves just under 500M available on the slice I initially created. There is no need to reboot at this time, as the disk driver reloads the partition tables on the next access if the disk is not in use. Since we haven’t mounted anything, we’re good to go. Remember that the numbering for the disk starts at zero, i.e., our first partition is /dev/c0d0p0, and our first slice is /dev/c0d0p0s0.

Set the new slice as bootable by issuing the following command:

# installboot -m /dev/c0d0p0 /usr/mdec/masterboot

Create your swap space, and turn it on:

# mkswap /dev/c0d0p0s1
# mount -s /dev/c0d0p0s1

Now, we will create a filesystem for the /usr partition on /dev/c0d0p0s2:

# mkfs /dev/c0d0p0s1
# readall -b /dev/c0d0p0s1 | sh
# mount /dev/c0d0p0s1 /mnt
# cpdir -v /usr /mnt

This will copy all of the data from the floppy-mounted /usr partition to the /mnt directory, where the disk-mounted /usr partition resides. You can now mount the new /usr directory instead of using the floppy:

# umount /dev/c0d0p0s1
# umount /dev/fd0
# mount /dev/c0d0p0s1 /usr

This is where things get a little hairy. In the usage.txt file, we are instructed to switch back to the ROOT.MNX image to make the root partition and fill it with data. But, if you switch back to the ROOT.MNX image in VirtualBox, and mount it as follows, you can look in the /mnt directory with ls and see that there are some problems:

# mount /dev/fd0 /fd0

So, if the ROOT.MNX image won’t work now, what do we do? Reboot! Type halt at the prompt, and the system will move to the fd0> prompt. Go ahead and power off the virtual machine, or type exit and reset the box through VirtualBox. Then start it back up. Make sure you are booting from the ROOT.MNX image.

When prompted for a device to mount as /usr, simply provide the device we filled earlier, /dev/c0d0p0s1. Again, log in byt typing “root” at the login prompt. From here, we can move on from the instructions in usage.txt:

# mkfs -i 512 /dev/c0d0p0s0
# mount /dev/fd0 /fd0
# mount /dev/c0d0p0s0 /mnt
# cpdir -v /fd0 /mnt
# umount /dev/fd0

You can issue ls /fd0 after mounting it, and see that the file names are correct, unlike they were previously.

The /mnt/etc/issue file (or /etc/issue, when the device is mounted as root) creates the “use setup” line when the system boots, so it can be removed, or replaced with one of your choosing. The /mnt/etc/fstab file (or /etc/fstab, when the device is mounted as root) needs to be modified to reflect the new partitions. I used sed and cat to make my edits:

# sed ’s/t=unknown/t=\/dev\/c0d0p0s0/;s/r=unknown/r=\/dev\/c0d0p0s1/’ \ /mnt/etc/fstab > /mnt/etc/fstab.new
# cp /mnt/etc/fstab.new /mnt/etc/fstab
# cat >> /mnt/etc/fstab << EOF
> swap = /dev/c0d0p0s2
> EOF

Now unmount the new root partition and make it bootable:

# umount /dev/c0d0p1s0
# installboot -d /dev/c0d0p1s0 /usr/mdec/bootblock boot

Now we’re all set! Simply issue halt again, as before, and reboot the machine. Don’t forget that you need to unset the boot floppy device, or change the boot order in VirtualBox to have it boot from the hard disk.

Use your new system wisely!

/cs

Mosso, the Cloud Hosting offering from market-leading hosting provider Rackspace, has received a rave review about their on-the-fly scalability under load.

Mosso is a hosting platform that allows you to be flexible with your configuration. Their Linux offering includes PHP 4 & 5, MySQL 4 & 5, Ruby on Rails, Perl, and Python technologies for building your application. Their cloud is, from their website, “an advanced, enterprise-level hosting platform that beats the pants off of running your own servers – and scales easier, too.”

The platform is easy on the budget, too. I’d rather not talk numbers here, so, contact Mosso for more information!

/cs

This tutorial will set up a basic virtual user config for vsftpd on a RHEL5-based system.  I recommend that you make backups of existing config files before implementing this solution, in case you need to revert.  This allows virtual “guest” users to log in with individual usernames and passwords and have access to a base directory.

I suggest building the initial files in a directory of their own first, and the steps below outline copying the files into place.

Six simple steps:

Step 1: Create the virtual user database.

Create a text file with each username/password pair on two lines, i.e:

# cat /etc/logins.txt
username
password
username2
password2

Then, use BerkleyDB to has the file, and change its permissions:

# db_load -T -t hash -f logins.txt /etc/vsftpd_login.db
# chmod 600 /etc/vsftpd_login.db

Step 2: Create a PAM file which uses your new database.

# cat > vsftpd.pam
auth required /lib/security/pam_userdb.so db=/etc/vsftpd_login
account required /lib/security/pam_userdb.so db=/etc/vsftpd_login

# cp vsftpd.pam /etc/pam.d/vsftpd

Step 3: Set up the location of the files for the virtual users by creating a “wrapper user”.

# useradd -d /home/ftpsite virtual

Step 4: Create your vsftpd.conf config file.

# cat > vsftpd.virtusr.conf
anonymous_enable=NO
local_enable=YES
write_enable=NO    # change to YES if you want uploads available
anon_upload_enable=NO
anon_mkdir_write_enable=NO
anon_other_write_enable=NO
chroot_local_user=YES
guest_enable=YES
guest_username=virtual
listen=YES
listen_port=10021    # optional
pasv_min_port=30000    # optional
pasv_max_port=30999    # optional

# cp /etc/vsftpd.conf /etc/vsftpd.conf.orig
# cp vsftpd.virtusr.conf /etc/vsftpd.conf

Step 5: Restart vsftpd.

# /etc/init.d/vsftpd restart

Step 6: Test.  I think you can figure this one out on your own.

Hold on to the logins.txt file, and simply update it and rebuild the DB when you need to add a user.  This allows several users access to the same directory and files.  Only give access to people you trust.

/cs

So, I read an article that is both sensical and scary:

Flaming Mountainside: Breeding Internet Superbugs

I get a LOT of junk mail in my USPS mailbox in front of my house, and I pretty much ignore it, as long as it doesn’t look terribly important. It goes right into the trash.

I have to agree with vixie in the above article; the issue is not being solved, just pushed away.

In the Linux Admin world, currently, in order to have a mail server that will send to Yahoo! and AOL, among others, you already have to jump through plenty of hoops:

• Email DNS – Forward and reverse DNS entries for the IP and A record.
• SPF – Sender Policy Framework
• DomainKeys - By far, the worst, in my opinion.

These are just a few things to try, and still, the spam keeps flowing, because the spammer has a need to get his message through.  I suppose I could try Spamassassin or Postini.  Some companies even offer to manage the spam problem for you (and they do a pretty darn good job of it, too!).

As the old saying goes, “Necessity is the mother of invention.” Continuing to “fix” the spam issue will cause the number of spammers fluent in loopholes to exceed the number of hackers available to fix the problem.

All in all, how do we fix the spam issue? The same way we fix the junk mail issue: The delete key.

/cs

I re-installed Windows XP on my laptop for the sole purpose of playing American McGee’s Alice. And I blew away grub.

So, to reinstall it, I booted the Hardy LiveCD, and mounted some things:

$ sudo mkdir /mnt/ubu
$ sudo mount /dev/hda5 /mnt/ubu/
$ sudo mount -t proc none /mnt/ubu/proc
$ sudo mount -o bind /dev /mnt/ubu/dev

I was able to determine the appropriate partition to mount by running “fdisk -l” before-hand.

Once mounted, I chrooted into the existing installation:

$ sudo chroot /mnt/ubu/ /bin/bash

Once in, I ran the following, and received the listed error:

# grub-install /dev/hda
/dev/hda does not have any corresponding BIOS drive.

Crap. What to do now? So, after a little Googling, which I am quite fond of, I found the answer:

# grub-install –recheck /dev/hda
Probing devices to guess BIOS drives. This may take a long time.
Searching for GRUB installation directory … found: /boot/grub
Installation finished. No error reported.
This is the contents of the device map /boot/grub/device.map.
Check if this is correct or not. If any of the lines is incorrect,
fix it and re-run the script `grub-install’.

(fd0) /dev/fd0
(hd0) /dev/hda

Success! I can now boot myself back into a realm of happiness known as the Hardy Heron!

/cs

So, how can you tell if the system you are using is 64-bit capable under Linux or just x86?

It’s easy. Run the following command:

$ cat /proc/cpuinfo | grep -y flags

In the output, look for the ‘lm’ (that’s L M) flag.

$ cat /proc/cpuinfo | grep -y flags
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc pni monitor ds_cpl cid cx16 xtpr lahf_lm
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc pni monitor ds_cpl cid cx16 xtpr lahf_lm

The ‘lm’ flag stands for “Long Mode” and is only present on 64-bit processors, and determines that you have the capability of running a 64-bit OS. This is from thefollowing:

/usr/include/asm/cpufeature.h: #define X86_FEATURE_LM (1*32+29) /* Long Mode (x86-64) */

Particularly, on my local system, which runs 32-bit Ubuntu Feisty, I found that the file containing this was in /usr/src/linux-headers-VERSION/includes.

It seems I may have a box to rekick soon, just to give it a whirl.

/cs

God help you if you have Plesk.

But, if you do an you need to receive the system messages emailed to root, simply execute these commands as root on your RHEL server:

# echo `hostname` >> /var/qmail/control/locals
# /etc/init.d/qmail restart

After this, log into the CP, and click Server->Edit. Change the Administrator Email to the address you want root’s mail sent to, and voila! it goes.

This will also work for postmaster and mailer-daemon.

/cs

I log into my server several times a day through SSH. Sometimes, it gets a little frustrating trying to type that oh-so-secure random password every time. I’m a hunt’n'peck typist, and typically get my password wrong a few times.

So, I’ve implemented an SSH key setup that I use to connect between machines.

Here’s how:

First things first, on your local box, create a public/private key pair:

$ ssh-keygen -t rsa -C thom

Once you have done that, you will be prompted for a filename in which to save the key pair, and an optional password for the key itself. I think the password negates the use of the key, and chose to leave it blank.
Now, cat out the public key. Mine is located at ~/.ssh/id_rsa.pub:

$ cat ~/.ssh/id_rsa.pub
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAsFwZH6hxcjQiErOT+GKJc1T2LZS62gHGPvr4bcy
Y3m5sWoqpz09Kn82ch7SJCG4yxswix9Hy/vvTa09YUqGdBISxkvaz8BZk7fC1YdOTt6R/2cc5CJK
7xMVuBlTvMIXkzQPQ+N1CQx2DOBbeGgqESU7uiahXZYN8HbF5DAwG73CfJMmkNF8lEWQXx
7F2o/R56G8//gx1swHMC/hVYY9zXdRj3zy7ladK7kQ7L6ST06d7ayXd7jnLwSvJRuXiUiLDfBPDTlik
WUruL0egkAoHxyrcCX+vtPJnJXK5hQFG6P7d975xJZLGecEhwMg5qpDmTWcycqEfBEvxd8YVo
AlWJQ== thom

Log into your remote server as you always have, but for (hopefully) the last time. Assuming you have already ssh’d into the box, there should be a .ssh/ directory in the remote user’s home directory. Paste your local public key into the ~/.ssh/authorized_keys file on the remote machine. Create the file if it doesn’t already exist.

Make sure that the authorized_keys file has permissions of 600. Issue the following commands to make sure:

$ chmod 600 ~/.ssh/authorized_keys
$ ls -l ~/.ssh/authorized_keys

Now, you need to make sure sshd is configured to allow for key-based entry. In the /etc/ssh/sshd_config file on your server, make sure the following options are set:

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys

I would recommend at this point also making sure that the option “PermitRootLogin no” is set, as allowing root SSH login is a pufickly hu-yooge! security risk!

Now that those options are in place, go ahead and restart sshd for your system. On Linux, issue this command as root:

# /etc/init.d/sshd restart

Now, if everything progressed according to plan, when you login to the remote server, you should be greeted with a shell prompt, not a password prompt.

If you are still having problems, check your work. The .ssh directory’s file permissions should look similar to this:

$ ls -lh ~/.ssh
total 16K
-rw——- 1 thom thom 388 Jan 3 18:01 authorized_keys
-rw——- 1 thom thom 887 Jan 3 18:14 id_rsa
-rw-r–r– 1 thom thom 230 Jan 3 18:14 id_rsa.pub

There you are! No more fumbling with passwords, and still just as secure as ever! Now, I would suggest creating an encrypted USB disk on which to back up your RSA keys.

So, the other day, I plugged in my USB drive with the encrypted partitions I created, and realized I was tired of having to wonder which one was which before checking the size or contents.

The reason it’s an issue is because I created two encrypted partitions. One is 5MB for SSH and GPG keys and whatnot, and the other is the 512M partition discussed in the article.

To alleviate the naming issue, I found the device-mapper object that corresponds to each partition and issued the following command for watch corresponding name and device-map. Device-mapper basically uses a generic process to map one block device to another:

sudo tune2fs -L nameOfEncryptedPartition /dev/mapper/Luks_crypto_partitionID

Now, when I plug in my USB drive, I am greeted with “enc1″ and “enc2″, which are the set labels for the partitions, rather than a random selection by udev labeling each as disk-N, where N is a digit.

Problem solved.

/cs

Every once in a while, the need arises for a certificate without the exorbitant price tag that comes with Thawte or Verisign. Of course, those outfits will give you a certificate that matches the CA certs built in to common browsers like Firefox and Safari. Or IE. But I don’t like IE. But for a personal email account over SSL or for an admin site for your company, why not create a self-signed certificate?

Using openssl one can do a multitude of cool things, including creating your own self-signed certificate.

Here’s an example of using a self-signed cert for web content.

For the exercises presented here, you’ll need access to the following:

1. An Apache Webserver. It will match the configuration options I have presented here.
2. A domain name. Just an example.com in your hosts file will work, or visit Network Solutions to purchase one.
3. Access to the command line on the server that has your Apache install, with appropriate permissions to edit the configuration.

For my examples, I will be running Red Hat Enterprise Linux 4 (Update 6) and Red Hat’s Apache version for the implementation, and will be running Ubuntu 7.04 Desktop for some of the command examples. Typically, there shouldn’t be much difference in the commands run, but the implementation can vary from distro to distro. Ubuntu and Debian’s stock Apache implementations and configuration are very complex compared to Red Hat’s.

Once you have the requisites taken care of, then let’s get a little familiar with the openssl command.

Open up two terminals, and issue the following command:

$ openssl req -x509 -days 365 -newkey rsa:1024 -keyout hostkey.pem -nodes -out hostcert.pem

Press enter. You’ll see that this will spit out a LOT of information. To sum up, it basically says “Please tell me some information.” You’ll be prompted for the following information:

• Country Name (2 letter code)
• State or Province Name (full name)
• Locality Name (eg, city)
• Organization Name (eg, company)
• Organizational Unit Name (eg, section)
• Common Name (eg, YOUR name)
• Email Address

Some key things to note are that the state should be fully typed out, ie, Texas, not TX. Also, the Common Name is the name of the URL that will be using the certificate, such as secure,ozymo.com.

This will create a hostcert.pem and hostkey.pem file containing the certificate and the ke, respectively:

$ ls -lah *.pem
-rw-r–r– 1 chuck chuck 1.4K 2008-02-17 15:09 hostcert.pem
-rw-r–r– 1 chuck chuck 891 2008-02-17 15:09 hostkey.pem

OK – so, we have our certificate and key now. Let’s give them a couple tests to make sure they work properly.

In the same terminal we just used, let’s issue these two commands to test continuity between the cert and the key:

$ openssl x509 -in hostcert.pem -noout -modulus
$ openssl rsa -in hostkey.pem -noout -modulus

These commands will spit out a modulus of the cert and key, and if they are the same, then the cert and the key match. If they differ, something has gone terribly wrong.

Another test we can set up includes creating a test server and test client, and this is where that other terminal you opened comes in. In the first terminal, which we have been using, issue the following command:

$ openssl s_server -accept 9000 -cert hostcert.pem -key hostkey.pem

This command will be followed by some output and the word “ACCEPT”. This means it is listening on port 9000. Now go to the other terminal, and run the following command as root or with sudo:

$ sudo netstat -ntpl | grep :9000
tcp 0 0 0.0.0.0:9000 0.0.0.0:* LISTEN 1668/openssl

As you can see, the server is listening. In the other terminal, run this command to make a connection. I have included some of the output, as I really wanted to illustrate only two key points in this example:

$ openssl s_client -connect localhost:9000 -CApath /etc/grid-security/certificates | grep handshake
depth=0 /C=US/ST=Texas/L=XXXXXX XXXX/O=The PiRS Network/OU=ozymo.com/CN=www.ozymo.com/emailAddress=chuckstearns@ozymo.com
verify error:num=18:self signed certificate
verify return:1
depth=0 /C=US/ST=Texas/L=XXXXXX XXXX/O=The PiRS Network/OU=ozymo.com/CN=www.ozymo.com/emailAddress=chuckstearns@ozymo.com
verify return:1
SSL handshake has read 1414 bytes and written 252 bytes

As you can see on line three of the ouput, there was a verification error because we have a self-signed certificate, but, on line 8, you can see that the SSL handshake was indeed successful.

So, let’s get this configured in an Apache vhost so that we can have secure, encrypted content. Sounds like fun, right?

First, you will need to upload the certificate. Do this in whichever manner suits you. I used scp.

Log into your server via SSH. Open the Apache configuration file in which your SSL vhosts reside. Add the following lines to enable the certificate we just created:

SSLEngine On
SSLCertificateFile /path/to/hostcert.pem
SSLCertificateKeyFile /path/to/kostkey.pem

I leave the rest of the configuration up to you, as it is your server.

Now, all that has to be done is to restart Apache, and visit the common name you used in the cert with the prefix https://

Remember that you will receive a cert error, because it it self-signed and not registered with any CA. Maybe we’ll cover creating a CA in a later entry.

/cs

Recently, I came across an issue. I wanted to transfer some information from place to place, and have access to it, and make sure that no one else had access to it.

So, why not set up an encrypted USB device?

The cryptsetup package in Ubuntu, which provides a command-line interface for configuring encrypted devices, along with the dm-crypt device-mapper target, which allows for transparent encryption of block devices using the new Linux 2.6 kernel’s cryptoapi, when combined with Linux Unified Key Setup, a USB device and a little inginuity, provide the key. And without the key specified in the setup of the encrypted device, there is no access to the data. Just what I like! So, how does one go about this seemingly-quite-complicated-and-may-take-several-tries-before-getting-it-right setup? Here’s how:

1. First things first – acquire a USB drive. I use a 4GB Lexar Firefly. It’s white.

PLEASE NOTE: If you have ANY data on the drive that you want to keep, make a backup of it right now. Where we’re going, we don’t need data. Yet.

I have it partitioned as follows (you may not need this much stuff):

$ sudo fdisk -l /dev/sda

Disk /dev/sda: 4059 MB, 4059561984 bytes
125 heads, 62 sectors/track, 1023 cylinders
Units = cylinders of 7750 * 512 = 3968000 bytes

Device Boot Start End Blocks Id System
/dev/sda1 * 1 190 736219 6 FAT16
/dev/sda2 191 320 503750 83 Linux
/dev/sda3 321 450 503750 83 Linux
/dev/sda4 451 1023 2220375 5 Extended
/dev/sda5 451 452 7719 83 Linux
/dev/sda6 453 1023 2212594 6 FAT16

To partition the drive, you can use fdisk, or gparted, or what you are comfortable with. This isn’t a tutorial for that, though, so I won’t go into more details than I have at this point. Basically, though, we need at least two partitions: One for the encrypted section, and one for regular use.

In case you are wondering why you wouldn’t want to encrypt the whole thing, read on. You don’t want to have to type your password in every time you plug it in. You want to be able to put the new driver that you downloaded on your cable internet on your Grandma’s computer so you don’t have to wait 3 hours for it to download over dialup. Your wife asks you to get the updated budget off of her computer, and you haven’t convinced her that Linux RULES! yet. I can go on for hours, but it comes down to this: If the whole thing is encrypted, it negates the usefulness of the USB drive. That said, let’s continue.

2. Install the cryptsetup package on Ubuntu using the following command (or do this on your distro the appropriate way):

# sudo apt-get install cryptsetup

3. Reboot, or load the new dm-crypt module:

# sudo modprobe dm_crypt

4. Look at /etc/fstab and see whether or not there are any entries pertaining to the USB drive, as these will likely cause it to fail to mount. Make sure that both of the partitions on the USB drive are NOT MOUNTED!! use the mount command to list your mounted devices, and see if the appropriate block device is there. If it is, unmount it:

# umount /dev/sda1

5. Create the encrypted filesystems for secure storage on the FIRST partition you created:

# sudo luksformat -t ext2 /dev/sda1

6. Create the vfat partition for normal USB drive use on the SECOND partition. I have given the partition the name LEXAR:

# sudo mkfs.vfat -n LEXAR /dev/sda2

7. If Ubuntu decided in partitioning to remount the drive, unmount it. Remove the drive from the USB slot. Reinsert the USB drive, and voila! Ubuntu will prompt you for a password in order to mount your encrypted USB partition.

Now, you have a secure place to store sensitive information, such as SSH or PGP keys, password lists, pictures of your lovely wife, or anything else you come across. Now, you can feel free to restore the data that you backed up earlier.

/cs

I like bash.

It is simple and straight forward. In the words of Master Foo, “Is it he who writes the ten thousand lines, or he who, perceiving the emptiness of the task, gains merit by not coding?”

One of the easiest things to do in a bash script that has more than one function is to add the capability of the script to allow arguments to specify it’s action.

continue reading…