I had a problem with my mac where I couldn't save any kind of file on the disk anymore. I had to reboot OSX lion and reset the permissions on files and acls.
But now when I want to commit a repository I get the following error from ssh:
Permissions 0777 for '/Users/username/.ssh/id_rsa' are too open.
It is recommended that your private key files are NOT accessible by others.
This private key will be ignored.
What permissions levels should i give to the id_rsa file?
Intersting message here. Operating Syatems are smart enough to deny remote connections if your private key is too open. It understands the risk where permissions for id_rsa is wide open (read, is edittable by anyone).
{ One might have changed your lock first and then open it with the keys he already had. }
PS:
While working on the multiple servers (non-production), most of us feel need to connect remote server with ssh. A good idea is to have a pice of application level code (may be java using jsch) to create ssh trusts between servers. This way connection will be passwordless. Incase, perl is installed - one may use net ssh module too.
Keys need to be only readable by you:
600 appears to be fine as well (in fact better in most cases, because you don't need to change file permissions to edit it).
The relevant portion from the manpage (
man ssh
)provide 400 permission, execute below command
The locale-independent solution that works on Windows 8.1 is:
GID 545 is a special ID that always refers to the 'Users' group, even if you locale uses a different word for Users.
There is one exception to the "0x00" permissions requirement on a key. If the key is owned by root and group-owned by a group with users in it, then it can be "0440" and any user in that group can use the key.
I believe this will work with any permissions in the set "0xx0" but I haven't tested every combination with every version. I have tried 0660 with 5.3p1-84 on CentOS 6, and the group not the primary group of the user but a secondary group, and it works fine.
This would typically not be done for someone's personal key, but for a key used for automation, in a situation where you don't want the application to be able to mess with the key.
Similar rules apply to the .ssh directory restrictions.
I have came across with this error while I was playing with Ansible. I have changed the permissions of the private key to 600 in order to solve this problem. And it worked!