This is something that has kept coming back to bite me recently.
When you are setting up public-key authentication on OpenSSH, you must be very careful of file ownerships and permissions. In many stock unix setups, this isn’t a problem. But in any environment where you are relying on a lot of group access to files, it is easy to slip up and earn yourself a system that will silently fail to authenticate (unless you turn on debug level verbosity).
- The private key must be readable only by the user initiating the connection.
- The authorized_hosts file must be writable only by the account accepting the connection.
Sounds simple enough, ne?
The real trick is that group write permission anywhere up the directory tree can render these precautions meaningless. Who cares if I can’t see into .ssh in your home directory if I can manipulate your home dir itself?
- $HOME and $HOME/.ssh must be locked down on the destination host.
A general good rule of thumb for permissions might be something like this:
ammon@farnsworth:~$ <b>chmod 755 .</b>
ammon@farnsworth:~$ <b>chmod 700 .ssh</b>
ammon@farnsworth:~$ <b>chmod 600 .ssh/authorized_keys</b>
Obviously, this gets kind of tricksy if you want to do something like allow SCP file transfers to the Apache user on a system… and their home dir is /var/www… and your web developers have group write access to this dir.
In situations like that, you have two options. First, you could disable the permissions checks (by turning off StrictModes in the sshd_config), but that’s not advisable. Second, you could make a separate home dir for the apache user with the restrictions in a place where they won’t interfere with anyone’s work.