~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 laptop that I use as my primary computer, and a desktop machine that I attach it to at work (both run linux).  I use synergy to connect the two so that I don’t have to remember which mouse is attached.

By default, synergy is quite insecure.  On the contrary, running synergy inside an encrypted ssh tunnel is quite secure.

I have two machines:

1. My laptop: synclient
2. My desktop: synserver

So, I use the keyboard/mouse from the desktop to control everything.  I assume that you are already aware of synergy and that you already have a working config.  Oh, ant that you are running Linux.  Oh, and that both of your Linux machine name the other one in their /etc/hosts files.  Oh, and that you have your synergy config in /etc/synergy.conf.  Now we don’t have to have everything all cluttered with flags.

There is no guaranty here that any of this will work on or improve the security of Windows.  You’ve been warned.

I log into both machines, and start up the synergy server on my desktop (I have a synergy.conf in /etc, so there is no need to pass it a config file argument with -c):

chuck@synserver:~$ synergys

I then log into my laptop, and do the following:

chuck@synclient:~$ ssh -f -N -L 24800:synserver:24800 synserver
chuck@synclient:~$ synergyc localhost

Now, it’s a pain to have to do that every time.  So, I put an alias in my ~/.bashrc:

alias synclient=’ssh -f -N -L 24800:synserver:24800 synserver && synergyc localhost’

Now, I can log into my laptop, once I’ve started synergys on the desktop, and run this:

chuck@synclient:~$ synclient

Now, the SSH tunnel has been configured, and the synergyclient started, all in one command.  No mess, no fuss. No password leaked on the net.

/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

Oh, my.  What a weird couple weeks it’s been for my laptop…

I started with Alpha5, in which suspend worked.  Alpha 6 also supported suspend.  Both with the open-source ati driver upon install.  Beautiful!  Thank you Ubuntu for having an awesome distro!

Supposedly, the xorg-driver-fglrx package in the Ubuntu repos for the Hardy development version addressed the suspend/resume issues that have been the bane of Linux geeks with newer ATI cards eveywhere.  I, for one, did not notice that the issue had been resolved.

I DID notice, however, that out-of-the-box, so to speak, suspend worked with the open-source ati driver.  I could suspend, resume, hibernate, etc.  But, I’m whiney, and wanted my ever-so-cool desktop effects (mostly for the transparent terminals).

Upon installing this xorg-driver-fglrx package, my suspend/resume functionality broke.  Ouch.  That’s a beta-killer if ever.

I have tried every sort of configuration imaginable, and googled every combination of keywords for fglrx, suspend, hibernate, sleep, resume, ati, proprietary, and on and on.  I found several people (with different cards and different configurations) that were successful in manipulating the /etc/default/acpi-support file in such a way that suspend just worked.  Hoorah for them!  I was still stuck.

I have a Gateway MT3705 with an integrated ATI Radeon XPRESS 200M graphics card:

$ lspci -vv
01:05.0 VGA compatible controller: ATI Technologies Inc RC410 [Radeon Xpress 200M] (prog-if 00 [VGA controller])
Subsystem: Gateway 2000 Unknown device 0318
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 255 (2000ns min), Cache Line Size: 32 bytes
Interrupt: pin A routed to IRQ 19
Region 0: Memory at d0000000 (32-bit, prefetchable) [size=256M]
Region 1: I/O ports at 9000 [size=256]
Region 2: Memory at c0000000 (32-bit, non-prefetchable) [size=64K]
[virtual] Expansion ROM at c0020000 [disabled] [size=128K]
Capabilities: <access denied>

Pulling info from dpkg, I can see the version and supported cards:

$ sudo dpkg -p xorg-driver-fglrx | grep ‘Version\|Xpress’
Version: 1:7.1.0-8-3+2.6.24.11-12.31
* Radeon Xpress: 1200 series, 1100 series, 200 series

All in all, it is “supposed” to work.  I have NO idea why it does not.  I am not that far along.  In fact, I don’t think the issue is with the driver, after my most recent discovery.

I have successfully been able to suspend and resume my computer for several hours now!  Hoorah!

Here is what I have done:

I changed a few things around in the /etc/default/acpi-support file, as per the instructions as cchtml pertaining to Gutsy and Feisty, because they have not yet gotten the Hardy page together (since it’s still alpha, i understand!).  Here is my current /etc/default/acpi-support file:

$ sed ‘/^#/d;/^$/d’ /etc/default/acpi-support
ACPI_SLEEP=true
ACPI_HIBERNATE=true
ACPI_SLEEP_MODE=mem
MODULES=”"
MODULES_WHITELIST=”fglrx”
SAVE_VBE_STATE=false
VBESTATE=/var/lib/acpi-support/vbestate
POST_VIDEO=
USE_DPMS=false
DOUBLE_CONSOLE_SWITCH=false
HIBERNATE_MODE=shutdown
LOCK_SCREEN=true
STOP_SERVICES=”"
RESTART_IRDA=false
ENABLE_LAPTOP_MODE=false
SPINDOWN_TIME=12

This is not stock.  However, I have made enough changes to it that I am not sure what the stock implementation is anymore!  It works now, so I’m cool with it.

Now, if I try to suspend via gnome-power-manager, or the Logout button, it will sleep and blink at me slowly and drearily, but will abruptly tell me to piss off when I try to wake it.  Ever poked a sleeping bear?  Same thing.

However, if I open my terminal and run this command (in bold), I can sleep and resume, as you can see by the output of the script (not in bold):

$ sudo /etc/acpi/sleep.sh force
ifdown: interface eth0 not configured
ifdown: interface wlan0 not configured
* Shutting down ALSA…                                                 [ OK ]
* Saving the system clock
* Setting the system clock
Ignoring unknown interface eth0=eth0.
Ignoring unknown interface wlan0=wlan0.
* Setting up ALSA…                                                    [ OK ]
FATAL: Module acpi_sbs not found.
FATAL: Module acpi_sbs not found.

So, when it suspends, I get a grey-and-white-blinky-screen-of-death, and then *poof!* it’s out and peaceful.  When returned to a wakeful state, I am greeted with my desktop and session information that I left behind.

Once concern I have is that the screen is not locked when the computer awakens, so theoretically, anyone could awaken my laptop and overtake me completely.  Since it is nearly always within arm’s reach, I am not terribly worried.  I worked around this issue as such:

$ sudo /etc/acpi/sleep.sh force && gnome-screensaver-command –lock

For me, this is too much to remember, so I have set up a little alias in my ~/.bashrc file called simply “sleep” that performs this command for me when I type, well, “sleep”:

$ grep “alias sle” ~/.bashrc
alias sleep=’sudo /etc/acpi/sleep.sh force && gnome-screensaver-command –lock’

I am a terminal junky, and am perfectly fine with this.  But, some people are not, so here’s a GUI-type version of the above.  These can be run by pressing Alt-F2, and copying in the commands.  You will likely be prompted for a password:

$ gksu gedit /usr/local/bin/sleeparound.sh

Type into file:
#!/bin/bash
gksu /etc/acpi/sleep.sh force && gnome-screensaver-command –lock

$ gksu chmod +x /usr/local/bin/sleeparound.sh

Now that the tough terminal part is done, simply add a custom launcher to the panel (right-click the panel, click “Add to Panel…”, click “Custom Application Launcher”) that calls this command.  It will prompt you for a password, then sleep, and lock your screen when it wakes up.

Cool.

Now, make a note that during my research, I found that some people had networking problems after resume, particularly pertaining to wireless.  I did not, so will not delve into that, but two key things that I saw (which could be added to the sleeparound.sh script) wereunloading and reloading the driver modules for the particular net interface, and restarting the Gnome Network Manager.

I gotta say, I love Linux.

/cs

UPDATE 080319: A smoother version of the command to use for sleep involves using the -S flag for sudo, which causes it to read from standard input.  For example, in .bashrc, the alias “sleep” would be comprised of this:

alias sleep=’gnome-screensaver-command –lock && sleep 3 && cat ~/.passfile | sudo -S /etc/acpi/sleep.sh force’

So, in your home directory, issue the command ‘cat > ~/.passfile && chmod 400 ~/.passfile’ and type in your password.  Setting the permissions to 400 disallow other users from reading the file (other than root).  You can also replace the command in the shell script we created above with this, as well.

This version will lock the screen, then sleep, whereas before, it would sleep, then lock the screen on wake.  Sorry - I wrote the last one at like 2 in the morning.  /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