[Bug 2141] New: ssh-add refuses to load a public key with permissions that are "too open"

[bugzilla-daemon at mindrot.org]

https://bugzilla.mindrot.org/show_bug.cgi?id=2141

            Bug ID: 2141
           Summary: ssh-add refuses to load a public key with permissions
                    that are "too open"
           Product: Portable OpenSSH
           Version: 6.0p1
          Hardware: All
                OS: Linux
            Status: NEW
          Severity: minor
          Priority: P5
         Component: ssh-add
          Assignee: unassigned-bugs at mindrot.org
          Reporter: buck.alex+openssh at gmail.com

I store my private key, encrypted, on a USB drive so that it's not
littered on every system I use. The USB drive is formatted with fat32
for compatibility with multiple operating systems, but fat32 doesn't
support standard UNIX permissions, so Linux mounts the tree using fake
permissions (usually 755). Unfortunately, ssh-add makes assumptions
that cause it to believe that these permissions are unsafe and shows a
fatal error when attempting to load the private key. To get around
these assumptions, I had to copy my SSH key to the local system (since
I couldn't trick ssh-add into reading from stdin), which reduces the
security of my key by creating a second copy on a storage medium that
isn't constantly in my posession.

Here's the error in question:
> kbuck at debian:~$ ssh-add /media/usb0/sshkey-armored.pem
> @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
> @         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
> @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
> Permissions 0755 for '/media/usb0/sshkey-armored.pem' are too open.
> It is required that your private key files are NOT accessible by others.
> This private key will be ignored.

I've taken a cursory look at the source code for openssh-6.2p2 and it
appears that this bug is still present.

Here are some possible ways of improving this:
1) Turn the "UNPROTECTED PRIVATE KEY FILE" fatal error into a warning.
2) Don't fire the "UNPROTECTED PRIVATE KEY FILE" error if the key file
is encrypted (or make it a warning instead).
3) Add a -f or --force that overrides the "UNPROTECTED PRIVATE KEY
FILE" error.
4) Attempt to detect whether the key is stored on a volume that doesn't
support UNIX permissions and skip the error (and possibly show a
different warning).

-- 
You are receiving this mail because:
You are watching the assignee of the bug.