I have an encrypted FAT volume (for compatibility) containing a private key file and other sensitive data.

I want to connect to my server through SSH using my private key, but of course, as FAT doesn't support file permission, it ignores my key saying its permissions are too open.

So currently I'm copying it somewhere else on my hard drive with 0600 permissions, using it and then securely erasing it, but it's a pain.

Is there a way to bypass permission check on this very ssh/scp command line ?

Edit: Precision: it was a TrueCrypt volume on OS X.

On the solution: The accepted answer below solved my problem (using a SSH key file located on a TrueCrypt volume with Mac OS X), but it is a workaround. Looks like there is no way to "bypasssh key file permission check".


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).

  • works perfectly Nov 10 '09 at 11:03
  • I couldn't get a FAT-formatted volume to get the right permissions with this method. However, selecting "Mac OS Extended" and selecting the option to mount on other operating systems allows me to set the permissions with chmod.
    – emptyset
    Jan 24 '14 at 21:31
  • This worked wonderfully. When I mount the secure volume I mount to specific point in my home directory. I found that I had to replace the value of 'none' with the explicit name of the mount point. Oct 16 '15 at 1:42
  • 1
    This works even when there is no /etc/fstab file on newer OS X. Just make a new etc/fstab file with the above
    – iggie
    Apr 15 '19 at 20:06

Adding the key from stdin worked for me:

cat /path/to/id_rsa | ssh-add -k -
  • 2
    why does this have not one upvote? it works out of the box without mounting and you're using an ssh-agent anyway, didn't you?
    – pscheit
    Nov 14 '17 at 12:05
  • 6
    works like a charm - should e the accepted answer
    – hdave
    Jun 8 '18 at 20:03
  • 1
    This got me in. Using WSL Ubuntu. Thanks!
    – mydoglixu
    Jun 6 '19 at 18:10
  • This actuall worked for me, thanks
    – Yousaf
    Mar 24 '20 at 20:56
  • In cygwin on Windows 10, I get Error connecting to agent: No such file or directory when trying this suggestion. Which is a bummer because file permissions are really screwed up in cygwin. Jun 1 '20 at 2:43

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.

  • seems like there is no simpler option Nov 5 '09 at 17:07
  • 1
    that is so wrong - but very cool :)
    – warren
    Nov 6 '09 at 18:44
  • 1
    @warren: I did preface it with 'crazy'. :-D
    – Kyle Smith
    Nov 6 '09 at 20:06

What about adding StrictModes no to your /etc/ssh/sshd_config (and the reload/restart sshd) ?

edit: oops, this option is server-side only :/


If I recall correctly, ssh-agent does not check for key permissions. So this might work:

[ -S "$SSH_AUTH_SOCK" ] || eval $(ssh-agent)
ssh-add path/to/id_rsa
  • FYI, This does not work. ssh-add does check file permissions.
    – Kyle Smith
    Nov 5 '09 at 16:18

Can you modify your mount options (umask, uid and gid) to suit?

  • AFAIK No, it's a TrueCrypt volume, my only option is to mount it as read-only and ssh still complains it's 0777 Nov 5 '09 at 15:01

My recipe for dealing with Cygwin/Windows permissions and ssh keys in cygwin is as follows.

open first cygwin64 terminal, start ssh-agent there

eval $(ssh-agent)

change permissions of (any) key just before adding to the agent

chmod 400 my_key.pem
ssh-add my_key.pem

open future cygwin64 terminals out of this one to ensure they inherit the environment and have the ssh-agent with the key(s)


I'm also using a vfat formatted Truecrypt volume for the same compatibility reasons. But on Linux, using tcplay to mount it from a script.

In such a case, instead of editing fstab, the solution is to directly add the umask=077 option to the mount command.

This is the relevant part of the script I use:

uid=$(id -u)
gid=$(id -g)

# ... losetup and tcplay commands ...

sudo mount -o nodev,nosuid,uid=$uid,gid=$gid,umask=077 /dev/mapper/$mnt_name $mnt_point

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.