Sign up ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It's 100% free, no registration required.

I have a set of SSH keys to login to accounts and servers. However, ever since I moved my main work profile to a USB drive (for sync and ease of use among other reasons) I have been unable to directly use the SSH keys in the profile for authentication, having to create local copies instead.

Normal SSH workflow usually goes

ssh-add $HOME/.ssh/id_server_key 
ssh username@domain

Which works without problems. However, to prevent each machine from having a copy of my keys I moved them to an xexternal drive, USB formatted as vfat. Then workflow should become like this:

ssh-add  /run/media/myself/USB/.ssh/id_server_key
ssh username@domain

...Which doesn't work. SSH complains about doing something to protect me:

Permissions 0644 for 'id_server_key' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
bad permissions: ignore key: id_server_key
Permission denied (publickey).

Which, while I can understand, it's not really protecting me in this case.

The USB drive automounts in my distro, with a fmask of (I think) 022. I could unmount and remount the USB drive with a fmask of 077 but that would (1) require superuser privilege each time and (2) affect every single file in the device, not only the SSH keys.

I've tried creating a symlink to the key, even with previous use of umask as I've seen in some tips&tricks:

cd .ssh
umask 077
ln -s /run/media/myself/USB/.ssh/id_server_key 

But the permissions can not be used this way for a symbolic link, so I get nothing.

So, what options do I have here available if the goal is to not have a physical copy of the key on the machine? One of the machines is a family laptop that goes to various places, so I have an interest in avoiding some of the keys being discovered.

So far I've considered the following:

  • Is there for example an option to force SSH (ssh-add primarily) to accept the keys from the external device? (I presume there should be - most programs follow a "I-know-what-I'm-doing" flag, but so far I can't find it in the manpage.
  • Setting a bindfs over the .ssh/ directory, but the problem is that the directory is non-empty (as it contains known_hosts and other data).
  • fuse-zip-ing the keys over /dev/shm seems to be a possible path as well.

EDIT: As per @Gilles 's comment, yes, bindfs solves the issue. After a checking of the manpage, initial testing succeeded using the following invocation:

bindfs -n -r -p 0700 -o nonempty /run/media/myself/USB/.ssh/ ~/.ssh 

Which binds disallowing access from other users (apparently even from root!), read-only, with reflected 0700 permissions. That reflection was the part that I lacked when working with bindfs originally. The nonempty flag was needed because of preexisting files such as known_hosts. This preserves the original workflow exactly except for an extra warning messae about not being able to add information to known_hosts (which in the end I might not mind).

Of course, I'm bindfs-ing to another directory now (in /dev/shm) as originally suggested to make things slightly easier.

I'm not as conspiranoid so as to encfs my USB drive (yet) so privacy-wise this is good enough for me.

share|improve this question
Is there a way of telling your automounter to mount the stick with umask 077? (You usually don't care about permissions for group and others on a stick.) – michas Jan 12 '13 at 0:20
To my knowledge it should be possible to do it via udev or similar (hal, udisks?), but I've found no good, centralized documentation on the process so far. – Luis Machuca Jan 12 '13 at 16:14

3 Answers 3

up vote 1 down vote accepted

ssh-add doesn't have an option to bypass its check of the key permissions. You could recompile the program and disable the check.

A bindfs should work. You don't need to mount it at ~/.ssh, mount it at a special-purpose location and write a script that does ssh-add ~/.ssh-private-keys-bindfs.

Note that ssh is right in that your setup is pretty insecure. You must make sure never to plug that drive into a computer where you are not the sole user.

share|improve this answer
Good point about bindfsing it at a different location, I'll test it. And a better point about the security. While I'm the sole user of the distro, I'm not the sole user of the physical computer. – Luis Machuca Jan 12 '13 at 0:14
@LuisMachuca If you're the only user of that operating system on that computer, you're probably fine (while hardware backdoors are possible in theory, they are not (yet?) common in the wild). But if there are other users using the same operating system (even if they aren't logged in at the same time as you), they can easily read your keys. – Gilles Jan 12 '13 at 0:18
Luckily I'm not too concerned with HW backdoors (yet?). Laptops are too finicky for dongle-backdooring and at that point the attacker is close to me enough that on a practical level is more feasible. – Luis Machuca Jan 12 '13 at 17:19

It is a permissions problem, as identified by this line:

Permissions 0644 for 'id_server_key' are too open.

It happens, because your permissions are too open on the private key, then ssh cannot guarantee the authenticity of the key, and will balk at using it.

So taking into account the VFATness of the thumbdrive (which doesn't support changing the permissions), you could do something like adding this line into /etc/fstab file:

LABEL=USB none msdos -u=USERID,-m=PERMS

Where USERID is your numerical userid, and PERMS is 700. This should tell the automounter to always mount the USB drive as that user, with no rights for group or other.

In case your file-system would support permissions, it would be much easier to fix it by:

chmod 700 /run/media/myself/USB/.ssh
chmod 400 /run/media/myself/USB/.ssh/id_server_key
share|improve this answer
The asker had already identified the problem. Your proposed solution doesn't work since this is a FAT filesystem that doesn't have file permissions. – Gilles Jan 12 '13 at 0:04
ah. i missed the part about vfat. thanks, @gilles. someday i'll learn how to read more carefully. :) – Tim Kennedy Jan 12 '13 at 0:09
I might try this one, though bindfs solved the problem for me. Thanks. – Luis Machuca Jan 12 '13 at 16:59

You can load the external key through the named pipe, e.g.

$ mkfifo -m=600 fifo
$ cat /external/media/.ssh/id_server_key >fifo | ssh-add fifo

Using process substitution also could work (using bash/zsh-like syntax):

$ ssh-add <(cat /external/media/.ssh/id_server_key)

assuming your anonymous pipe has the right permissions (check via: stat <(:)).

Or try loading it from the standard input:

$ cat /external/media/.ssh/id_server_key | ssh-add -
share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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