I find the Apple Keychain very useful, but need to protect my keys -- apparently more than Apple anticipated. On all my machines, I used to have my login keychain set to close after a couple hours of "inactivity". This was very intrusive, as it also locked SSHKeychain, even if I was actively using ssh keys (since Keychain didn't know SSHKeychain was actively being used). I recently discovered the security command. Now I have a cron job which flushes my login keychain when I'm done working for the day/night on all my machines, and it's enabled me to crank up login's inactivity timer. Twice a day, cron runs "security lock-keychain ~/Library/Keychains/login.keychain".

Locking the Keychain has revealed several problems (which I have reported to Apple). First, .Mac syncing assumes the Keychain is always unlocked. This makes a certain amount of sense, but means .Mac syncing doesn't really work unless you leave your .Mac password always available in a keychain. To address this, I use a separate keychain (lowsec) for the relatively low-security .Mac password -- lowsec never locks itself (until I reboot). I'm not happy about this, but it's the best I could do without giving up the one really useful .Mac service.

This leads to the second problem (a straight bug): extra password prompts. If I use my account password for my login keychain, it should be automatically unlocked whenever I unlock the screensaver (just as it's unlocked when I log in after a reboot). But it isn't. I still get prompted to unlock my login keychain after unlocking the screensaver. What's worse, I often get a couple prompts for my login keychain, and on an untrusted laptop I typically get a couple more for lowsec (for a stalled .Mac sync, and to set my iChat status). On the laptop, SSHKeychain is set to lock my keychains when it sleeps, and SSHKeychain is not selective -- it locks all keychains (also reported to Bart).

The untrusted laptop found another serious problem. I don't trust FileVault, so I created a 2gb AES-encrypted disk image with Disk Utility. I moved ~/.ssh and ~/Library/Keychains (yes, I know about ~/Library/Caches/) onto the disk image, and created symlinks from the original locations. The bug I found is that, if the Keychain can't be used (perhaps, say, because ~/Library/Keychains is a dangling symlink, and it's configured to use one or more keychains there), Disk Utility is unable to present the password dialog for an encrypted disk image. This meant because I'd "broken" the Keychain by dismounting the disk image containing my keys, I was unable to remount the disk image to "fix" the keychain, because the broken keychain was preventing disk mounting! I escaped the vicious circle by moving aside the symlink and creating a new ~/Libraries/Keychain directory, which un-broke the Keychain enough that I could get the disk image back online. Now I leave ~/Library/Keychains/lowsec in the normal place, so the Keychain is functional, and manually specified the locations of my (normally unavailable and mostly empty) keychains on the disk image, so they're available when it's mounted.