The SSH client (in all versions, on all UNIX-like platforms) that I've ever used refuses to connect using a key file if it's permissions are "too open" with no option or bypass provided to the user. This can potentially undermine the client's own goal of protecting keys under some circumstances such as the one posted here: http://forums.debian.net/viewtopic.php?t=31129 My circumstance is similar in that I have an ecrypted USB key with underlying VFAT filesystem which is used for securely storing all my encryption keys. It is sometimes used under a guest account on systems with a default install to which I do not have root access. The refusal of the client to connect using this secured file forces me to copy it to a home or temp directory and change the permissions. Aside from being inconvenient it also introduces the risk that either the user forgets to delete the key from the temporary location or that the key is scraped from the hard drive at some future date (such as after the machine it was used on is retired). This also defeats the purpose of keeping the key on a USB stick which is to keep it OFF of local hard drives. Some recommendations: 1) An override for the user. Inform them, but allow them to "take it under advisement", so to speak. 2) An ssh + ssh_config option to control this behaviour.
Solution: don't store keys on filesystems that lack permissions support Workaround (as of 5.9): ssh-add - < /path/to/key We don't intend to relax the permissions requirement
Set all RESOLVED bugs to CLOSED with release of OpenSSH 7.1