| Summary: | ssh-add refuses to load a public key with permissions that are "too open" | ||
|---|---|---|---|
| Product: | Portable OpenSSH | Reporter: | Keith Buck <buck.alex+openssh> |
| Component: | ssh-add | Assignee: | Assigned to nobody <unassigned-bugs> |
| Status: | CLOSED WONTFIX | ||
| Severity: | minor | CC: | djm |
| Priority: | P5 | ||
| Version: | 6.0p1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
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.) Set all RESOLVED bugs to CLOSED with release of OpenSSH 7.1 |
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@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).