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).
Don't use a password. Generate a passphrase-less SSH key and push it to your VM.
If you already have an SSH key, you can skip this step…
Just hit Enter for the key and both passphrases:
$ ssh-keygen -t rsa -b 2048
Generating public/private rsa key pair.
Enter file in which to save the key (/home/username/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/username/.ssh/id_rsa.
Your public key has been saved in /home/username/.ssh/id_rsa.pub.
Copy your keys to the target server:
$ ssh-copy-id id@server
id@server's password:
Now try logging into the machine, with ssh 'id@server', and check-in:
.ssh/authorized_keys
Note: If you don't have .ssh dir and authorized_keys file, you need to create it first
to make sure we haven’t added extra keys that you weren’t expecting.
Finally, check to log in…
$ ssh id@server
id@server:~$
You may also want to look into using ssh-agent if you want to try keeping your keys protected with a passphrase.
Best Answer
I feel your pain. I have all my ~/.*rc files under version control (Subversion), has worked great since I started in 1998, using CVS. One way to do it, is to check out all your rc files like this when you stand in your home directory:
This way the config files will also be synced and updated across the various computers when you run svn update.