Ubuntu Tutorials

You might remember a recent tutorial I did on securing VNC via SSH with the -via option of vncviewer.  Today I started looking into it more with one of my students and we wanted to make the -via option use compression.  By default it just creates a basic tunnel with SSH and doesn’t let you get much more specific.  We figured out how to make it follow more specific instructions!

update: the environment variable is valid in vncviewer version 4.1.2, but apparently not in Feisty’s current version, 3.3.7.  Solution 1 applies to Ubuntu, Solution 2 does not apply to Ubuntu (successful on RHEL5 and most likely recent Fedora series)

Solution 1:

vncviewer will look to client-side configuration files for its settings.  You can create a ~/.ssh/config file for any of your ssh connections and, which might look like this:

Host alias

HostName hostname

Compression yes

User username

…you get the idea.  This will connect to the HostName value when you “ssh alias”, using Compression and the User specified.  You can use any valid ssh value in this config (see man ssh).  Using client-side configuration like this can cut a long ssh configuration down to a much shorter one.  ie;

The vncviewer will look for this file when used in combination with the -via switch and use compression if set to on, as above.  Test it with and without the Compression value and see if you find a difference in performance.

Solution 2:

vncviewer uses an environment variable to start an ssh connection.  By default it looks like:

VNC_VIA_CMD=/usr/bin/ssh -f -L “$L”:”$H”:”$R” “$G” sleep 20

You can find this using one of the following:

env | grep VNC_VIA_CMD

or

strings /usr/bin/vncviewer | grep ssh

The second method of altering it’s connection settings are to update this environment value and tell it to use Compression.  This would be done using the following:

export VNC_VIA_CMD=’/usr/bin/ssh -C -f -L “$L”:”$H”:”$R” “$G” sleep 20′

(that uses single quotes around the entire value and double quotes on the embedded values.  This is important.)

So, if you do a lot of work with VNC I hope you’re using the -via option for SSH tunneling.  Now you can also compress your connection for better performance on slower networks.  What are your results here?  Do you notice much of a difference?  I have only tested this on a LAN so the speeds are fast in the first place.  Anyone want to share their results out over the public interweb?

If this article has been helpful, please consider linking to it.

Please consider downloading the latest version of folding instead.

After some more user feedback I have made some additional adjustments to the Folding @ Home Automated Installer and am releasing revision 0.3. Updates in this release include:

• General bug fixes
• More efficient collection of finstall script
• Execute permissions (u+x) now set within archive
• Improved init script creation

You can download your copy below if you’d like.. and thank you again to all that are running the Folding client and contributing to Stanfords medical research.

Folding @ Home Automated Installer (gzip)

Folding @ Home Automated Installer (bz2)

Folding @ Home Automated Installer (zip)

update: if you’re already running the Folding client there is no need to upgrade. Remember, this is simply an installer and any updates don’t affect the client itself or the working process.

I have spent the last two hours on Google, Ubuntu Forums and IRC trying to find a seemingly simple solution to a problem.  I’m not able to find anything yet… so I thought I’d blog the question and see if any of the general public had an answer for me.

Question: How can I un-map a keyboard binding?  My macbook F10 key has been mapped to right-click (although I don’t remember doing it) and I would like to have F10 actually do F10.

I’d appreciate any comments for tips on doing this.  I’ve already looked at my xmodmap.  I don’t see it defined in there.  I don’t think it is in my xorg.conf either…

Cheers

Today’s post isn’t so much a tutorial but more of a discussion or educational topic on grub.  It was inspired by the original post here and continued discussion in the comments.  I thought I would outline some suggestions on securing the grub boot loader and why Ubuntu adding a “rescue mode” entry in grub is not a security flaw and is really not any less secure than any other distribution.

(based on how long this entry has become I added the split post.  If you’d like to read a long entry, click read more.  If you’re not in the mood for a 10min read, relax and forget it.)

To understand this you’ll need to be familiar with Linux runlevels.  There are six default runlevels in the Linux base system.

0 (zero) is basically the shutdown runlevel.

1 (one) is single user mode.

2 (two) is a multi-user mode, minus NFS support.

3 (three) is a multi-user, command line based mode.

4 (four) user-defined / undefined.

5 (five) multi-user, graphical mode.  This is generally the default runlevel on desktop / laptop machines.

6 (six) is basically the reboot runlevel.

For the most part you don’t often use runlevel 1 or 2, primarily only use 3 on servers and 0 and 6 are used when you shutdown or reboot the machine.  5 is most likely the default on your system now.

The reason that I outline this topic in relation to grub, security and “rescue mode” is that the option included in Ubuntu for “rescue mode” is basically just an entry that boots the machine into runlevel 1 instead of the default 5.

The default behaviour for runlevel 1 is to boot to a basic shell, not require a login and allow the user to do recovery or maintenance.  Some people feel that this is a security flaw and that allowing root access to a machine via an entry in grub is simply absurd.  This same access can be achieved on most Linux distributions.

If you’d like to try it yourself (yes, this also applies to Fedora, RHEL, etc) boot your machine and press a key at grub.  You should see a menu for your available kernels and can boot any of them by selecting them and pressing ENTER.

You’ll also notice a small paragraph of command tips below the menu.  This outline explains that you can edit grub entries within this interface by pressing ‘e’ or ‘a’ to append to the entry.  To boot your machine to the “recovery mode” that Ubuntu creates simply ‘a’ (to append) and add one of the following to the kernel line: 1, s, S, or single.  These options will boot your machine to runlevel 1 or single user mode, give you a shell prompt for maintenance or recovery and not prompt you for a password.

Again, this can be done on most other distributions.  It is not limited to Ubuntu and is not a security flaw.  It is built this way to allow a user to recover a lost password, update or recover configuration files, and otherwise fix an unbootable machine.

Now that we understand that the system is designed this way and this access can be granted on most any machine you have local access to we might want to discuss how to lock down the grub system to not allow grub editing.  Securing grub will, of course, further harden your machine from this potential threat but also lock you out of recovery if you forget the passphase to access grub.

Now if you decide you’d like to lockdown grub to not allow any editing you’ll need to edit the /boot/grub/menu.lst file.  This file includes any available bootable kernels you have, the Ubuntu recovery mode entries, memtest86+ and any other OS you have setup.  Most of this file is pretty straight forward, but because of the method Debian/Ubuntu use to update this file you need to make updates in certain places.  If these changes are not made in the right place they will be overwritten the next time you update your kernel.

There is an AUTOMATIC KERNELS LIST section which builds the basis for your kernel updates within grub.  We don’t need to edit anything within this section (as it will be overwritten on the next update anyway).  What we can do though, is update some of the global options that you see near the top of the file.  These include the ‘default’ value, ‘timeout’ and ‘hidemenu’.   These don’t offer any security though.  What we can add is a password entry that will limit any grub updates or alteration without the password.

The first step to do this is run the ‘grub-md5-crypt’ command.  This will generate an md5 hash of a password of your choice which can be then added to grub.

Add a line entry in grub (anywhere in the same area of the options mentioned above) using the following syntax:

password --md5 (two dashes md5) <hash>

replace <hash>, of course, with the hash value outputted by grub-md5-crypt.  You’ll end up with something like:

password --md5 $1$nL5d0$36n6u8TaxOX9guBdKaGFx0

At this point, since this password is at the top of the file and not specific to any one entry, (which can also be done by adding the same syntax to individual entries) any updates to grub will require this password.  At this point, even local access to the machine will require a password before being able to suggest an alternate runlevel or using Ubuntu’s “recovery mode”.

Your Linux machine is now one step closer to being a hardened gauntlet.  Enjoy.

It has been one of those days.  I’m getting ready to head back to my hotel soon, but I just had to share a story with everyone.  If nothing else it is proof that the Linux command line is a very powerful tool.. if you take the time to learn it.

Here is the setting.  I’m teaching a class this week in Boston, MA.  It is the RedHat 300 “Fast Track” course, for preparing Linux administrators for the RedHat Certified Engineer Exam.  I’ve got a room full of very experienced geeks that have definitely kept me on my toes.  Some of the questions they’ve come up with… well let me tell you.  One in particular I just had to share.

One student decided to see what would happen if he filled up his drive using yum.  (For those not familiar with yum it is the RH/Fedora equivalent of apt-get or aptitude).  So he proceeded to do the following until his drive was at 100% capacity:

yum install a*

yum install b*

yum install c*

yum install d*

…. you get the idea.

He then posed the question: “How can I clean that up without re-installing the system?”

The first thought was to simply revert what he had done.  ‘yum remove a*’, etc.  We quickly realized that would not work because it would also remove packages that were required for the system.  Hmm.. we’d have to come up with something more specific.  Here is what we put together:

for i in `rpm -qai | grep -B5 'Thu 21 Jun 2007 03' | grep Name | awk '{ print $3 }' | grep -v kernel` ; do yum -y remove $i ; done

For those of you familiar with scripting and work in the shell it should make some sense.  For the rest of you, I guess I might have to explain.

This one command actually fixes his problem and keeps the system intact.

First we’re creating a loop so that the command will repeat itself for every package installed on the system (rpm -qai lists info for all installed packages).  We then grep through that output for todays date and the hour he began (grep -B5 ‘Thu 21 Jun 2007 03′), including the 5 previous lines.  Based on that we grep for ‘Name’ within that output (grep Name).  We then print a value from what we find there, which ends up being the package name (awk ‘{ print $3 }’).  We throw that through one more grep to search for anything that *doesn’t* match the kernel (grep -v kernel).  The output of all of this filtering is then assigned to the value of i, which then is run through the package removal command for each instance (yum -y remove $i).

In other words it scans all the packages on the machine, finds anything installed today during 3:00, pulls out the package name and removes it automatically.  I’d say this is proof yet again that the Linux command line is a very powerful tool if you know how to use it, and this is a good example why you should learn how to use it.

Can anyone think of a better way to do it?

SSH, what a wonderful tool. One of the crowning achievements of the modern world, with a hundred and one different uses. One of my favorite being that of tunnelling and proxying connections over it’s secure, encrypted goodness.

I thought I’d outline how to setup a proxy system using SSH that can be used by any application that supports SOCKS proxy. This includes Firefox, Thunderbird, Gaim/Pidgin and anything that subscribes to the Gnome “Network Proxy Preferences” found in System > Preferences > Network Proxy. note: this sets the shell environment values for: http_proxy and no_proxy.

The only two requirements you’ll need for this tutorial are an internet connection (of course) and access via ssh to a remote machine. In my case I connect from my laptop while on the road to a server available at home. This could just as easily be used between an office and home or visa versa.

Use a command similar to that below to create this SOCKS supported tunnel:

ssh -D port hostname

ie; ssh -D 8080 example.com, ssh -D 8081 example.com, ssh -D 8888 example.com. In this example I am using the 8000 range ports but you should be able to use *any* available outbound port. No need to specify other ports on the remote end like you do with traditional -L tunneling.

Once this connection is established you can set your proxy settings within the application (look for any proxy prefernces) or globally in System > Preferences > Network Proxy.

Select Manual Proxy Configuration, and enter “localhost” “port” (where port is the number used following the -D) in the SOCKS (4 or 5) field provided.

At this point you’re outgoing connections will be privately routed over said port to your remote server via ssh and then out to the outside world. Enjoy your privacy and circumventing network filters.

I need to thank Aaron for initially showing me the -D option.

Please consider downloading the latest version of folding instead.

Based on some more testing and user feedback I’ve done some bug squashing in my Folding @ Home deployment script. Attached are the updated v0.2 files.

FAH-installer.tar.bz2

FAH-installer.tar.gz

FAH-installer.zip

A few things to consider:

If you want to install the Folding @ Home client on your (single) machine unpack the archive and simply run:

chmod u+x FAH-installer.sh

sudo ./FAH-installer.sh

If you want to deploy the Folding @ Home client across multiple machines in your network run:

chmod u+x FAH-deploy.sh

sudo ./FAH-deploy.sh

note: the deployment script connects as the root user. You may need to temporarily activate the root user on Ubuntu networked machines for it to work properly.

I have gone a little longer than I had planned without posting so I’m here to drop a quick update on what is in the works…

First, I’m leaving for Boston for the week in a few hours.  If there are any fellow Ubuntu users that would like to meet up for dinner or something Mon – Thur let me know (email or drop a comment).  I’d love to get some suggestions on good eateries and have some good dinner company.

Second, version 0.2 of the Folding @ Home automation project will be due out Tuesday.  Look for that if you’re interested in helping the folding project or have had trouble with my original script.  I have worked out quite a few bugs in this release.

Third, if all goes well I hope to have my “Installing Ubuntu on a Macbook” tutorial complete.  It is very comprehensive, borrows from many sources and (hopefully) should become a one-stop-shop for all Ubuntu-on-Macbook needs.  Fingers crossed I can get it out this week.  It has been a few weeks in the making.

Off to get ready for the trip.  See ya’ll on the other side…

I was discussing VNC this afternoon with some students and the question came up on how to secure VNC.  As you may have noticed most network protocols do not have much for built in security.  Many rely on other programs for their network security needs, such as ssh.  This is also the case with VNC.

If you use VNC regularly to connect to other Linux machines you may want to consider adding a lower-layer of encryption with ssh.  Here is a quick run-down on how that is done:

If you look at the man page for vncviewer (man (1) vncviwer) you’ll notice there is a small section for -via.  The -via option, as outlined in the man page will do:

Makes the connection go through SSH to a gateway host.  The gateway should be the target host for best connection secrecy.

Basically this is saying that you can tunnel VNC over SSH within your connection command.  Let’s give it a try.

vncviewer -via user@host localhost:0

This, of course, will require that you have both ssh and vnc access to a remote machine.

This tutorial will outline how to connect your Linux machine (probably not distro-specific, but this was tested and created using Ubuntu 7.04) to dial-up networking via a Treo 700p Smart Phone. This method uses USB connection and requires a data plan with your service provider. I use Sprint as they have the cheapest unlimited data plan.

In speed tests over the last few days here I have achieved ~350+kbps up and down speeds. This actually beats some residential DSL speeds that I’ve seen. Not bad. Now for the good stuff…

There are two sections of this tutorial. The first is preparing the phone to share connection to the computer. The second is telling the computer how to connect to the phone. Neither are terribly complicated, just make sure you follow the steps carefully.

Step 1 : Configuring the Treo 700p

From what I understand Sprint changed something since the Treo 650 and now require you to pay extra to share a data connection to your computer. We, of course, don’t want to do that so we’ll use a small piece of third party software to help us share this connection. This application, which you’ll need to install to your Treo 700p is called USB Modem.

I should note that this is not free software and is for-pay software, neither are points that I’m thrilled about but when there aren’t any other tools for the job… (anyone want to reverse engineer some Palm code?)

There is a free trial of that application that will run for 14 days or 30 connections. I’d suggest using the trial to initially set this up and if you find that its something you use go ahead and pay the $24.95 for the full version.

In any event, you’ll want to download the USB Modem application and install the .prc file to your Treo 700p. This tutorial will not outline installing or syncing your PDA. This assumes you already have a method of doing that. Remember to install the application to your phone itself and not a memory card.

After installing the USB Modem application navigate to it on your phone, but do not yet ‘Enable Modem Mode’. We’ll do that in a minute.

Step 2 : Configuring the Linux machine

I should note before I dive into this section that the USB Modem archive also includes instructions for setting up Linux, OS X and Windows. If you have trouble you might want to double check those instructions for more details.

On Ubuntu 7.04 (yet untested on other distributions) you need to manually add a kernel module for the Smart Phone syncing to be properly recognized. You can do this manually (not persistent) by using the command:

sudo modprobe visor

If you would like to make this persistent, which is something I have done, you will want to append a line “visor” to the end of your /etc/modules file. This way the kernel will be watching for a Smart Phone / PDA connection. If you don’t make it persistent you’ll, of course, need to do it manually each time you plan on connecting.

In my situation, using Sprint and an EVDO network, my connection does not require any kind of username and password to connect to the data network. This simplifies the steps a bit, but if your provider needs such information it isn’t too much different. Please refer to the USB Modem instructions for where to add your username and password.

The first step (and simplest way I found to connect) is to copy the connection script from the USB Modem archive to your /etc/ppp/peers/ directory. I used this command (assuming you’ve unzipped the archive to your Desktop):

sudo cp ~/Desktop/drivers/linux/ppp-script-evdo-template /etc/ppp/peers/ppp-script-treo

After you have copied the EVDO template file to the location above you should be ready to make your connection. note: I had to close existing connections (eth0, wlan0, etc) for this to work. Can anyone else verify this?

At this point you’ll want to reach over to your Treo 700p and “Enable Modem Mode”. If you’d like to see that the machine is recognizing your phone you could take a look at /var/log/messages.

Now that the phone is set to “Modem Mode” run the following command on the Linux machine:

sudo pppd /dev/ttyACM0 call ppp-script-treo

This will post some output to the screen and tell you whether or not you’re connecting. If you are assigned a remote and local IP plus primary and secondary DNS you’re most likely connected. You should get your prompt back at this point. Try pinging a location to verify your connection.

ping -c3 google.com

If your ping works you’re set. Enjoy your ppp connection over your phone. Internet wherever you have phone service. w00t! If it didn’t work please leave a comment and we’ll see what we can do for you. (chances are differences in providers, EVDO vs EDGE, etc).