roguelazer's website

I've just purchased an iPhone 3G. I'll now make a few posts about my ordering experience.

Relying on the numbers of my friend Martin Pyne, the 2008 Democratic Primary is over and Barack Obama is the winner. Woo!

So, I got bored this weekend and installed Firefox 3 (beta 5, if it matters to you). It works pretty well — it's certainly faster than Firefox 2. However, there are a couple of annoying bugs that I'd like to post the solutions to for posterity:

If you use a dark theme (like I do), then many textarea and input form elements will be unusable because they will have a dark foreground color and a light background color. The solution to this is to add a userContent.css to ~/.mozilla/firefox/ /chrome. There are lots of guides on the Internet for this file, so I won't go into it. However, the difference from Firefox 2 is that now any sections that you want to actually be interpreted for reskinning "native" controls (like form input boxes) need to have a -moz-appearance: none !important; rule. There should, however, not be any @namespace directive.

The other annoying thing is that the Awesomebar thinks links should be green. Don't get me wrong, I like the awesomebar, and I like links, and I like the color green. But green really doesn't work with my theme. So I reskinned them, using the userChrome.css file in the same directory as userContent.css. Copying the example will get you the @namespace directive, which is important in this file. Then, the following lines will get you some nice blue-ish links (this color looks good on a dark background):

.ac-url-text {
    color : #8888cc !important;
}

You can thank grep for the relevant style class. Anyhow, I'd be interested to hear any of your opinions on Firefox 3. Otherwise, have a nice week-end.

I've mentioned sudo in these tips before. It's a neat little utility for executing commands as somebody else. Well, today I bring you a handy guide I found on using sudo. I already knew most of the stuff, but some of it was new, and it looks pretty good as a starter for new users. So enjoy this article on sudo basics by A.P. Lawrence.

Sorry readers, no *nix Tip of the Day today. Just a brief word about the recent Debian OpenSSL vulnerability.

I'm sure you've heard about Debian's OpenSSL "Disaster". The short of it is that while fixing a questionable line in the OpenSSL/OpenSSH key generator, the Debian maintainer accidentally removed most of its entropy generation ability. Debian users with OpenSSL and/or OpenSSH keys should go regenerate them now. I'll wait.

Anyhow, the other interesting thing I wanted to post about was this. It's some interesting math showing why you shouldn't be using DSA keys anyway.

Oh yeah, and I'm done with classes and finals now. :-)

tee is a handy little utility that probably all of you know about, but I just found this year. Consider the following scenario: you're maintaining your Gentoo Linux system and you need to add a line to /etc/portage/package.unmask. So you type

sudo echo "sys-kernel/gentoo-sources" >> /etc/portage/package.unmask

right? Nope! The way shell parsing works, that turns into

(sudo echo "sys-kernel/gentoo-sources") >> /etc/portage/package.unmask

which is most certainly not what you want, since you probably don't have permissions to /etc/portage/package.unmask. The solution is the tee utility. It would be invoked like the following:

echo "sys-kernel/gentoo-sources" | sudo tee -a /etc/portage/package.unmask

Well, this was a short post. Oh well. :-)

An important part of a *nix system is a good terminal emulator. For some, this means the classic xterm. The same xterm that's happy to use 7 MiB of resident memory for each instance. Or perhaps you run a full DE like Gnome and are happy to use gnome-terminal and enjoy 19 MiB of resident. Personally, I use rxvt-unicode (urxvt). It's a very lightweight version of rxvt which has neato features like full Unicode support and a daemon mode that lets you pool multiple instances. For example, my urxvtd processs is using 41 MiB of resident, but hosting 9 urxvtc clients (a little over 4 MiB per client). It's several sorts of awesome.

Now, another important part of the terminal emulator infrastructure is the terminfo library (successor to termcap). This library contains terminfo definitions for pretty much every terminal emulator out there and allows the shell to make intelligent decisions about things like fonts, colors, and sizes. Unfortunately, I said "pretty much every terminal emulator" for a reason. rxvt-unicode is not one of the terminal emulators that is part of the standard library. Thus, my prompt, which normally looks like [11:06] <roguelazer@CaveOfBirds> ~ % ends up looking like 33mCaveOfBirds> ~ % when I log into a server that I've never logged into before.

So, what's the resolution to this problem? It took me a while to find out, but the key is the tic utility (which stands for terminfo compiler). Terminfo descriptions are distributed as a (almost) human-readable source format. urxvt's can be found here. Once you've acquired a source file, simply run tic on it. If you run tic as a normal user, the compiled terminfo description will be installed to ~/.terminfo; if run as root, it will be installed system-wide in /usr/share/terminfo.

As usual, come back later for some new and exciting tips.

Continuing on my theme of SSH tips, today's Tip of the Day talks about the awesomeness of SOCKS proxying. As some of the more savvy among you may know, OpenSSH supports full Layer-2/Layer-3 VPN functionality using a tun device. This is an incredibly useful feature if you're off-site and need like-local access to home, work, school, or somesuch. But it requires root access, and is more than a little bit of a pita to set up. If all you need is access to things like the web, e-mail, and instant messaging, there's an easier way.

SOCKS is a transparent proxy protocol. Basically, you just tell your applications (like Mozilla Firefox or Pidgin) to connect to a SOCKS server, and all of your traffic is automatically redirected. If you're on the wrong side of a restrictive firewall, or not in the right intranet, and you have access to a SOCKS server, that's great. But most of us normal humans don't get access to a "real" SOCKS server.

And that's where yet another awesome OpenSSH feature comes in. OpenSSH has a single-flag SOCKS server built right in. Say your school computer is called, erm, remote, and you have a user there who is creatively named user. Now say you're off-campus and really want to look at the on-campus-only student roster. You could screw around with TCP forwarding over SSH, or perhaps try to run links on your school machine. Or you could just type ssh -D65500 user@remote (note: the "65500" part is not important. Any number between 49152 and 65535 can be used with no problem). This creates a SOCKS proxy that goes through remote, but listens on port 65500 on your local machine. So now you open up Firefox's Preferences, go over to Advanced->Network->Connection->Settings, and put in a SOCKS Host of "127.0.0.1" port "65500". It doesn't matter whether you select v4 or v5 for this purpose, since OpenSSH supports both.

Congratulations, you're now talking to the internet through a transparent proxy. When you're done, just restore Firefox's old settings and quit SSH.

Check back later for new and exciting things to do in the *nix Tip of the Day series!

Today's *nix tip of the day involves SSH and the magic that is Agent Forwarding.

SSH, as some of you know, is a handy way to connect to *nix systems in an untrusted environment. Its primary use is to allow one to remotely access a remote system and get a shell, securely. Basically, encrypted telnet. Of course, SSH has tons of other useful features (like tunneling, proxying, and multiplexing), some of which might come up in future Tips of the Day.

One of SSH's greatest features is its public/private key system. Basically, using private keys, you can allow much more secure access to a remote machine. If you trust your local machine, you can even allow passwordless access to remote machines if you have an unencrypted private key. Of course, this is a bad idea if you think people might be able to compromise your local private key, which is why SSH private keys can also be encrypted with a symmetric cipher (basically, a password). Using this gives you all of the in-transit security and power of private keys, but all of the local security of password authentication (something you have + something you know sort of deal). They're covered a great deal more in a retroactively-posted tip of the day — read back a bit.

This is all well and good, but there are times when typing your SSH key's passphrase is annoying. For example, the Z Shell allows for tab-completion of remote filenames over ssh (when using scp, for example). It is an awesomely useful feature that makes remote filesystems feel local without any of the muss of sshfs. However, if you have an encrypted private key (or password authentication), typing your password every <TAB> can be a pain. Hence, ssh-agent.

ssh-agent is a program that you will generally run as a wrapper around your session (this is done automagically on linux if you're running gdm). If you want to test this stuff, you can just run exec ssh-agent $SHELL from a terminal and then execute all of the commands from this tip in that shell. Now, let's say that you've put your private key in the standard ~/.ssh/id_rsa, and it's encrypted. At your newly-ssh-agent'ed shell, type in ssh-add ~/.ssh/id_rsa and type in your private key's encryption passphrase when prompted. Congrats — you can now ssh from this shell to any machine containing your public key without any password at all. Isn't that awesome? Try it out. I'll wait.

...

Now, this is well and good. But let's say that you just ssh'd to example.com using your super-duper ssh-agent, and you want to ssh from there to your other server at example.net. Do you need to copy your private key onto example.net and then type the passphrase there? That might be a bit risky, especially if you don't really trust the admins of example.com. I mean, the key is encrypted, so you're probably okay, but what if they're running a keylogger? Well, as long as you're using OpenSSH (which you most likely are), you're fine, thanks to the magic of agent forwarding. Log out of example.com, and then run ssh -A username@example.com. Note the -A. This turns on agent forwarding, and means that your login at example.com temporarily has the same access permissions as your local machine. So you can happily ssh user@example.net and get the happy password-free access without anything else. You can even agent-forward from example.com to example.net and build up a chain of secure authentication credential forwarding all the way back to your local machine. It's awesome.

Well, that's my tip for the day. Check back again in the future for more exciting things that other people have said and done before.

Hello kind readers, and welcome to by *nix Tip of the Day. It's finals week, and I'm sort of slacking, so I thought I'd post some of my accumulated folk wisdom on the Internet, so that it might help others.

Today's topic is SSH Private/Public Keys. If any of you are CS majors, or go to a tech-heavy school, or generally interact with Linux/OS X/Solaris/HP-UX/AIX/any other *nix, you've probably used SSH. SSH, at its most basic, is a replacement for telnet and rlogin; it allows you to get a shell at a remote machine. However, it does so securely (hence, Secure SHell) using strong encryption. SSH, particularly modern implementations like OpenSSH also has other subsystems like scp (a replacement for rcp, which is in turn a remote version of cp), sftp (a secure replacement for FTP), and such.

Most people, when using SSH, use password authentication. They type ssh user@host and, when prompted, type in their login password to host. This isn't necessarily a bad thing — it's braindead-easy to set up, generally secure, and works the same way as remote logins have since the beginning of time.

There are some problems with this setup. One of the most obvious is that if you offer password authentication, your system's security is only as good as its worst password. Every user that picks "god" or "password" as his password paints a giant target on your machine.

Enabling password authentication, even if all of your users have strong passwords, still makes you a target. There are plenty of botnets out there that connect to servers and try sshing in with random usernames (and root, of course, but I assume you have root login disabled/restricted in SSH. You do, right? If not, go do so.). It's unlikely that they'll ever break a good password, but that's still traffic hitting your box. Disable password authentication, though, and they go away. Botnets (thankfully) never try to connect using anything else.

So, password authentication isn't great. What should you do instead? Well, it turns out that SSH supports something called public key authentication. The basic idea here is that the remote user has a small file called a private key that they keep with them (on their laptop, or on a flash drive). This key allows them to access the remote server (optionally without any password at all, although this is discouraged on a flash key or laptop) more securely. The authentication is done using either a DSA or RSA with a key-length of between 768 and 2048 bits, which is all technical stuff that you don't care about. Let's talk about setup.

The first thing to do is to prepare the client system and generate the key. The following commands should take care of that:

if [ ! -d ~/.ssh ]  then
    mkdir ~/.ssh
    chmod 700 ~/.ssh
    ssh-keygen -t rsa -b 2048 -f ~/.ssh/id_rsa
    chmod 600 ~/.ssh/*
fi

When you are prompted for a password by ssh-keygen, you should enter something long that you will not forget. It should not be your account password. If you really trust the client system (for example, if it's a desktop machine with no remote login sitting inside a bank vault that nobody could ever break into), you can leave this field empty. But I do not recommend it.

But how do you go about using this key? Note that the keygen will have created a file called ~/.ssh/id_rsa.pub. This is your public key, and needs to be uploaded to every machine that you need access to. Let's call the remote machine remote and the local machine local. The following code should do what you need:

scp ~/.ssh/id_rsa.pub user@remote:~/local.pub
ssh user@remote
if [ ! -d ~/.ssh ] then
    mkdir ~/.ssh
    chmod 700 ~/.ssh
fi
cat local.pub >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys
rm local.pub
exit

If all went well, you should now be able to log into remote using your public key. If you attempt to ssh user@remote, you should be prompted "Enter passphrase for key '/home/user/.ssh/id_rsa'". Type in the passphrase you entered during the key creation step and you're all set.

If typing in this passphrase all of the time seems like a pain in the rear to you, you're not alone. Check back later for the next article in the series, on the use of ssh-agent. It's awesome, I tell you.

Note: I am not responsible for any borkage that these commands might cause. As far as I know, they're correct, but I still disclaim any and all liability. Yadda yadda yadda.

Updated 2008-05-13 00:55 to use correct permissions for the contents of ~/.ssh