Bypass ssh key file permission check
Solution 1:
Adding the key from stdin worked for me:
cat /path/to/id_rsa | ssh-add -k -
Solution 2:
AFAIK, there is no way to bypass the keyfile permission check with ssh or ssh-add (and you can't trick it with named pipe or such). Besides, you do not actually want to trick ssh, but just to be able to use your key files.
Indeed, TrueCrypt volume is supposed to keep your data private, so mounting the volumes as world-readable (default behaviour of TrueCrypt) is not really optimum. If you're using a FAT-formatted volume, you really should ajust the mount options, as Dan Carley suggested.
Although mount options aren't yet correctly supported by TrueCrypt for OS X (even if you launch TC using the command line interface and the mount options from the man page - already tried), OS X does support mount option defaults based on the volume name.
You need to know your user id (usually 501 if you are the first/only user of the computer). You can get it with "id -u".
Let' say you volume name is "PRIVATE" (volume names are in capitals), and your uid is 501, all you have to do is adding this line to /etc/fstab :
LABEL=PRIVATE none msdos -u=501,-m=700
You need to be root to create/edit this file (it is not present in default OSX install) :
sudo vim /etc/fstab
Next time you mount the volume, it'll have permission 700 and owner id 501.
This also works with USB drives (which are usually formatted in FAT, too).
Solution 3:
As a crazy workaround, you could make a disk image of an ext2 volume containing your private key and mount it as a loop device, then use your ssh key from there.
Make a 1MB empty file:
dd if=/dev/zero of=diskimg bs=1024 count=1024
Format it ext2 (Press Y when it says it isn't a device):
mke2fs diskimg
Mount it somewhere (as root):
mount -t ext2 -o loop diskimg /my/path/to/diskimg
Now you have a tiny ext2 filesystem that you can set permissions on. You could write a script to mount it and make sure those permissions have the right UID/GID based on whatever system you're on (since the UIDs may mismatch). It also requires sudo/root access to work.
Solution 4:
What about adding StrictModes no to your /etc/ssh/sshd_config (and the reload/restart sshd) ?
edit: oops, this option is server-side only :/