Ssh-agent is a great program that lets you add the password to your SSH private key to memory, and then you don’t need to type in the ssh key passphrase every time. The basic usage is that you start BASH as a child of ssh-agent, and then use a program called ssh-add to prompt you for the password and store it in memory.

On OS X, there’s a GREAT program called SSHKeychain that handles this, storing the password in your OS X keychain, so it’s really seemless.

On Linux, you need to type in “ssh-add” manually every time you want to store the key, and after that your SSH sessions will be seamless.

However, I’m always forgetting to do that, and thus getting prompted for the password. Too many seams. I added the following code snippet to the end of my .bashrc file, and thus, every time I open a bash shell, it checks whether ssh-agent has any keys in memory. If it does, the shell starts as normal. If ssh-agent doesn’t have any keys in memory, it prompts you for the password. Simple, and as seamless as I can make it.

## Add key to ssh-add if it has not been added.

ssh-add -l &> /dev/null
SSHADDRESULT=$?
if [ "$SSHADDRESULT" -ne "0" ]; then
ssh-add
fi

UPDATE 2008-07-02: Here’s a much more succinct way of writing that:

ssh-add -l &>/dev/null || ssh-add

Some background: There’s a very useful website located at whatismyip.com, which reports the IP you used to connect to the site. If you’re on a computer behind a router which does NAT (Network Address Translation), you can’t find out what your external IP is by issuing commands on the computer. Your computer’s address is (for instance) 192.168.1.5, but when traffic reaches the router, the router translates (with NAT) your address to an external IP address, such as 34.23.64.9 (an IP address I just made up).

WhatIsMyIP.com (and other sites like it) sprang up to fill that void, and give you a simple way of finding out what external IP address you’re using.

Ubuntu Geek’s script fetches the whatismyip.com page with wget, parses it to find the IP address, and prints the IP address.

I tried it on my OS X box, and it didn’t work, because wget isn’t installed on OS X — but curl, a similar tool, is.

So I started modifying the script to use curl — and discovered an interesting comment in the source code to whatismyip.com’s page:

<!–Please set your code to scrape your IP from www.whatismyip.com/automation/n09230945.asp Please set your code to hit this page at a REASONABLE pace. For more info, please see our “What’s New” page.–>

Hitting that link gets you just your IP address, which has two benefits over Ubuntu Geek’s implementation — it means you have no parsing to do, and it gives a SIGNIFICANTLY lower load to WhatIsMyIP’s servers. (It’s rude to slam someone else’s servers with an automated script — even though a script that simply fetches a web page once doesn’t slam a server, 10,000 people running that script would.)

Here’s my take on Ubuntu Geek’s BASH script:

#!/bin/bash

echo -n “Your external IP Address is: ”
curl http://www.whatismyip.com/automation/n09230945.asp
echo “.”

For comparison’s here’s Ubuntu Geek’s original script:

#!/bin/bash

echo Your external IP Address is:
wget http://Www.whatismyip.com -O – -o /dev/null | \
grep ‘<TITLE>’ | sed -r ’s/<TITLE>WhatIsMyIP\.com \- //g’ | \
sed -r ’s/<\/TITLE>//g’
exit 0

Moral of the story? Always look for a simpler way of doing things.

Well, there’s a standard way of doing that in Linux/Unix, called setuid. You set the “setuid bit” to on, and the program will run as the owner of the program. So, since it’s owned by root, a regular user can run a particular program, and have that program run with the permissions that root has. Very handy.

But I couldn’t figure out why the program was not being installed setuid root. I could see in the postinst script that the command was valid. I could cut-and-paste the chmod line (that set the setuid bit) from the script to the command-line, run it, and it worked perfectly. And there weren’t any other commands in the postinst script that affected permissions (the setuid bit is a permission bit) for that file.

However, there WAS a chown command later in the script. (It started in a parent directory and recursed into the directory with the C program I was dealing with.) Eventually, I narrowed it down to that chown line, and once I saw chown was the cause, I guess it sort of made sense. I was able to reproduce the problem by chowning a file after setting the setuid bit.

I guess from a security standpoint, you could do a lot of stupid things by setting the setuid bit (making a program operate as the owner of the program) and then changing the owner. So, to prevent you from shooting yourself in the foot, changing ownership of a file unsets the setuid bit.

Still, this seems somewhat counter to the philosophy of Unix — first, to not do unexpected things, and second, to give users approximately an order of magnitude more rope than they’d need to hang themselves. I can’t think of many other commands that silently prevent you from doing something that MAY be stupid. Unix usually assumes that you know what you’re doing — even to the point that you can enter a command to delete every file on your hard drive, and Unix will happily delete all your files without asking for confirmation. The fact that chown has this behavior was NOT obvious to me.

(This is a highly technical rant, and I’m writing it late at night after coding for a while — if it doesn’t make any sense, it’s probably me, not you.)

You can remove all “.svn” directories starting below “~/svn/exampleproject” — change this to suit your system — with the following command:

find ~/svn/exampleproject -name “\.svn” -exec rm -rf {} \;

To make sure that the above command is going to do what you want it to do, you may want to first generate a list of what it will delete (I highly recommend it).

find ~/svn/exampleproject -name “\.svn” -exec echo “rm -rf {}” \;