We’ve mentioned NFS several times as a potential security risk for SSH installations. Now we delve into more detail on this topic.
In today’s world of ubiquitous networking, it is common for your home directory to be shared among many machines via a network file-sharing protocol, such as SMB for Windows machines or NFS and AFS for Unix. This is convenient, but it does raise some issues with SSH, both technical and security-related.
SSH examines files in the target account’s home directory in order to make critical decisions about authentication and authorization. For every form of authentication except password, the various control files in your home directory (authorized_keys, .shosts, .k5login, etc.) enable SSH access to your account. Two things are therefore important:
Your home directory needs to be safe from tampering.
SSH must have access to your home directory.
The security of shared home directories is often not very high. Although the NFS protocol has versions and implementations that afford greater security, it is woefully insecure in most installations. Often, it employs no reliable form of authentication whatsoever, but rather, uses the same scheme as rsh: the source IP address and DNS identify clients, and a privileged source port is proof of trustworthiness. It then simply believes the uid number encoded in NFS requests and grants access as that user. Breaking into a home directory can be as simple as: