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

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.

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

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |djm at mindrot.org
             Status|NEW                         |RESOLVED
         Resolution|---                         |WONTFIX

--- Comment #1 from Damien Miller <djm at mindrot.org> ---
You can do "cat /path/to/key | ssh-add -" since openssh-5.9 if you
really need to.

We don't want to relax this check, it's a little blunt but it does
ensure that private keys have a basic level of protection. You might
also consider adjusting the mount options of your FAT filesystems so
that they are mount with more restrictive permissions (uid, gid, umask,
etc.)

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

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

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--- Comment #2 from Damien Miller <djm at mindrot.org> ---
Set all RESOLVED bugs to CLOSED with release of OpenSSH 7.1

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.