Recently in FLOSS Category

As any user of SSH is aware, the first time you connect to a remote host, OpenSSH caches the server's public key in ~/.ssh/known_hosts. If the server's private key ever changes, SSH will raise an ugly error alerting you of the risk that an untrusted third-party could be intercepting your new connection.

Unfortunately, the known_hosts file represents a small security risk. It contains a convenient list of all servers to which you connect. An attacker who gained access to your password or unencrypted private key would simply need to iterate down the list until your credentials were accepted.

OpenSSH can optionally hash the server names in known_hosts. This renders the file useless to prying eyes without impairing SSH's ability to check hosts against the list. Enabling this feature and hashing your existing known_hosts file is easy!

1. Add the parameter "HashKnownHosts yes" to your ~/.ssh/config.
2. Run "ssh-keygen -H".

Below the fold, I included a handy shell script that accomplishes the same thing.

One final consideration is your shell history storing your ssh commands. It's easy to configure bash to forget these. Just set HISTIGNORE="ssh *:scp *:sftp *" in your ~/.bashrc.

I'm sure most Mac users encounter situations when they're forced to use a Windows keyboard. In my case, I attach a Mini and ocassionally my MacBook to a KVM switch shared by Vista, Ubuntu, and a Windows keyboard.

Up until now, I've just dealt with the fact that Windows keyboards switch the Option and Command key locations. I've trained my brain to use the Windows key rather than the key immediately adjacent to the space bar when I need Command. Previous versions of Mac OS had a feature that remapped the modifier keys, but this was a global setting that remapped all keyboards whether they be Windows or not.

I was pleasantly surprised when I discovered this dialog under Leopard's keyboard system preferences.

That new drop down list at the top lets me create mappings for all keyboards or specific keyboards, identiifed by their USB device name. Very nice, Apple!

I wanted to do something very simple over the weekend. I wanted to set up my Windows Vista computer to backup automatically to a drive shared on the network by my Mac Mini. In this day and age, digital information has become so important in our everyday lives that one would hope this is now relatively straightforward, right?

First, let me say that I can accomplish this in my sleep on any non-Windows computer. I work, live, and play on unix operating systems. I know how to configure key pairs and schedule a regular cron job to rsync files over a secure ssh connection. These technologies have a significant learning curve, but they work consistently and reliably.

My first hurdle was Leopard's horrible SMB support. Enabling Windows file sharing on Leopard confronts the user with an intimidating dialog box that warns about storing passwords in a less secure manner. The password on my primary account is important, so I decided to create a separate backup user. Unfortunately, Leopard "sharing only" accounts don't appear on the list of accounts available for Windows file sharing. I had to create a full user account, complete with a home directory.

The next hurdle was logging in from Vista. As I discovered after a solid half hour of tinkering, Leopard's SMB support only accepts the account's full name, not the abbreviated short version.

Vista comes with a backup tool that only supports network backups to Windows file shares. Once I had file sharing with the Mac working, I happily pointed the backup tool at that location. Windows complained about not having "full access," and Leopard doesn't have any option for enabling a higher level of privileges beyond "read & write." So there goes that idea. My Vista computer doesn't store anything more valuable than saved games and screenshots. It's not worth the time to hack something together for automatic regular backups.

Microsoft, how about adding support for backing up to SFTP or WebDAV? These are not new file sharing protocols, and they work cross-platform!

And to be fair, Apple's Time Machine is equally frustrating when backing up to non-Apple computers over the network. Time Machine relies on specific features of HFS+, including a hack in Leopard to enable hard links for directories, so network backups must create an HFS+ disk image on the remote computer.

This news is a couple weeks old, but I wanted to mention it anyway. Several years ago I mentioned a flaw in MD5. Seeking a proof of concept, a team of researchers successfully forged a CA certificate that could sign any certificate they desired. The resulting certificate would be implicitly trusted by all major web browsers. The team presented their results at the 25th Chaos Communication Congress last month in Berlin.

I wanted to briefly describe their ingenious technique but gave up after realizing how many prerequisite concepts I'd need to introduce. Read their excellent paper if you're interested in the details. The team used a farm of PlayStation 3 consoles to compute a CA certificate that collided with a carefully crafted certificate issued by RapidSSL.

There's no immediate risk to users. This development is primarily a wakeup call to certificate authorities to stop relying on MD5 immediately. MD5 is broken.

I'm proud to say that this blog does not run PHP or MySQL!

PHP is the most prevalent web programming language thanks its ease of installation and popularity among web designers. MySQL is the most common open source database management system (on web sites, at least). Both are horrid pieces of software haphazardly thrown together. I'll surely rant about them later.

This blog is powered by Apache, Perl, PostgreSQL, and Movable Type with a little help from mod_include, all running on Ubuntu. (Alas, the FreeBSD VPS hosts were not as appealing.) I may be stuck using PHP and MySQL at work, but at least I can liberate myself at home!

The popular open-source Firefox web browser hit 50 million downloads yesterday. TechWeb estimates that 1 in 10 "business professionals" use Firefox, and that percentage is expected to double again next quarter.

I just ran into a fascinating and insightful discussion about web applications and the future of computing. The article includes lots of good dialog and many links to other related articles. My favorite is an article written by Joel Spolsky earlier this month: How Microsoft Lost the API War. His article touches on such diverse topics as backwards compatibility in the Windows API, the sudden stall in Internet Explorer development a few years back, the .NET framework, Microsoft's "bad bets" in the upcoming Longhorn, and the decline in rich clients. Enjoy!