Chuck's Blog

Yesterday I found myself stumbling around Amazon searching for Christmas gifts. Out of pure habit I checked the electronic gadgets section, and managed to find an interesting little device for around 50$ USD: The Zipit Z2.

It is marketed as a instant messaging device, but a quick Google search finds it capable of being flashed to run a basic copy of Debian. This makes it really cool, as it can then be used as a small, portable SSH terminal. And since by default an install of Debian has fairly little included the device can be fairly secure. This makes it suitable for running simple personal things, like alpine and irssi to keep in touch with people without giving up passwords to a possibly keylogged kiosk.

One thing to note though is that the device’s default firmware requires a subscription to use. Therefore when purchasing one of these you need to be sure to not select any subscription, else you will be charged around 150$ instead of 50$. If your tempted to use this as it is advertised consider flashing it to Debian, and installing a simple IM client. Even irssi connecting to a bitlbee server is more than sufficient for the average user.

ab (apache bench) is a command line program that comes with apache by default in most distributions. It allows one to run a quick and efficient test of how a server can handle a heavy load of clients.

To use it simply run (as root)

ab -n number_of_requests_to_try http://www.websiteyouwanttobenchmark.com/

Note that the trailing / is necessary for ab to function. Once run it will produce a easy to read status report showing how fast your server responded to the requests. From there you can optimize your webserver to handle the requests more efficiently, all without having to resort to changing variables in the dark.

Today I poured over some of my auth.log files as usual, and yet again to my disappointment there were several hosts that had spent around three to four hours hounding my server with login attempts every five seconds. Having a few hours of time to kill I decided to investigate one of the machines.

I managed to determine large quantities of information. Below is a snippet of the text file I logged my findings in:

Fedora Core (unknown version)
Default Apache 2 installation
- /var/www/html is directory for www files
- /cgi-bin/ does exist, but directory indexing is off

Port 21 (ftp), 22 (ssh), 80 (http), 443 (http) are open.

All this points to that the owner set up a machine, connected it to the Internet, and forgot about it. One would assume the owner would have at least have tried to secure this server with some simple things, but nope. FTP still had its default banner, the apache test CGI scripts were available, and the machine was not patched. (Apache and ssh were about 6 months behind the latest, most secure versions)

I assume the reason this machine was attacking servers was because of a rogue individual compromising its security. I of course did not check, but it is perfectly possible that the owner left a default user account with a common password, opening the avenue for a simple bruteforce attack. How ironic, considering this is what it is doing itself to other machines.

In conclusion, admins, PLEASE SECURE YOUR MACHINES! If you do not then you will likely have your box compromised, just like this one. And trust me, you do not want to be on as many blacklists as this unfortunate victim.

Around the end of October, Canonical (the company behind Ubuntu) announced the new release of Ubuntu, specifically version 9.10. A little after it was released I installed in on my laptop, and so far I’m pretty impressed. I haven’t tested it extensively, but I do use it enough on a day-to-day basis that I would have noticed any significant issues.

Heres a screen shot of my desktop. This is not an out of the box desktop, rather it is about 20 minutes of work customizing my install. This is better than previous versions, where customizing like this took a good solid hour.

Besides being easy to customize, the new version of Ubuntu offers several notable features. A quick list of the ones I have noticed so far:

• Much better Bluetooth device support
• Darker and more eyecandy-like login screen
• Faster boot time (About 60% faster on my laptop than 8.04)
• Better integration of instant messaging  and email into the desktop
• The default usage of the ext4 filesystem
• And finally a new, and very promising service known as “Ubuntu One”

I haven’t really noticed any issues so far with anything, but there were some reports from early adopters stating plenty of large issues. I believe the majority of them have been fixed now, though it’s still advisable to test from the live CD to make sure hardware support hasn’t disappeared.

One thing I look forward to seeing advance is the Ubuntu One service. So far it only syncs bookmarks on FireFox, contacts in Evolution, files, and allows for quick sharing of a desktop, but possibly later on it could support things like mail and instant messenger account settings.

So maybe you’ve gotten tired of entering your password every time you log in to your home server. Maybe you desire better security. Or maybe you want to run automated scripts from a remote box and have their results piped to a local file. (Yay nerdiness!) Regardless this article is for you.

I’m not sure how to do this if your using putty, (feel free to contact me if you know) but I do when it comes to any Linux/BSD based operating system with the standard ssh package. First off you need to generate a RSA key pair (or DSA, your choice) on your client machine. Do this by running

ssh-keygen -t rsa

And just use the default location for the keys to be saved when asked. Heres the big thing to remember: when it asks for a password, DO NOT give it one. If you do than you will have to enter it every time you use the keypair.

The next step is to copy the public key into the ~/.ssh/authorized_keys file on your server. If this file does not exist already simply run the following to copy it over

scp .ssh/id_rsa.pub user@remoteserver:~/.ssh/authorized_keys

Then try connecting to the server. It should instantly login. Now, if your authorized_keys file already exists then what you need to do is append your public key to it. A simple copy+paste usually works, just be careful not to break any lines.

And that’s how you setup public key authentication with ssh. You can also change your server’s ssh daemon confiuration file to disable password authentication if you wish, but be sure you have a backup method of obtaining access to your server if you lose your private key.