10.7. Remote Home Directories (NFS, AFS)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:
10.7.1. NFS Security RisksThe 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:
10.7.2. NFS Access ProblemsAnother problem that can arise with SSH and NFS is one of access rights. With the public-key or trusted-host methods, if the per-user control files are in the usual place, sshd must read the target account's home directory in order to perform authentication. When that directory is on the same machine as sshd, this isn't a problem. sshd runs as root, and therefore has access to all files. However, if the directory is mounted from elsewhere via NFS, sshd might not have access to the directory. NFS is commonly configured so the special access privileges accorded the root account don't extend to remote filesystems. Now, this isn't a truly serious restriction. Since one of the root privileges is the ability to create a process with any uid, root can simply "become" the right user, and access the remote directory. SSH1 and SSH2 use this mechanism, but OpenSSH doesn't currently have it. [Section 3.6, "As-User Access (userfile)"] You can work around the problem, but to do so you must make your authorized_keys file world-readable; the only way to let root read it remotely is to let everyone read it. This isn't too objectionable. The authorized_keys file contains no secrets; though you might prefer not to reveal which keys allow access to your account, thus advertising which keys to steal. However, to grant this access, you must make your home directory and ~/.ssh world-searchable (that is, permissions at least 711). This doesn't allow other users to steal the contents, but it does allow them to guess at filenames and have those guesses verified. It also means that you must be careful about permissions on your files, since the top-level permissions on your directory don't prevent access by others. All this may be entirely unacceptable or no problem at all; it depends on your attitude towards your files and the other users on the machines where your home directory is accessible.
10.7.3. AFS Access ProblemsThe Andrew File System, or AFS, is a file-sharing protocol similar in purpose to NFS, but considerably more sophisticated. It uses Kerberos-4 for user authentication and is generally more secure than NFS. The access problem discussed previously comes up for AFS, but it's more work to solve, and this time, OpenSSH is the winner. Since AFS uses Kerberos, access to remote files is controlled by possession of an appropriate Kerberos ticket. There are no uid-switching games root can play; sshd must have an appropriate, valid AFS ticket in order to access your home directory. If you are logged into that machine, of course, you can use Kerberos and AFS commands to get such a ticket. However sshd needs it before you've logged in, so there's a bit of a quandary. This need to transfer credentials from machine to machine isn't unique to SSH, of course, and there is a solution for it: ticket forwarding. It takes some special support, because it's sufficient to just copy the ticket over to the remote host; tickets are issued specifically for particular hosts. Ticket forwarding isn't a feature of Kerberos-4 generally (though it is in Kerberos-5), but AFS has implemented it specifically for Kerberos-4 TGTs and AFS access tokens, and OpenSSH performs this forwarding automatically. To use this feature, you must compile both the SSH client and server -- with-kerberos and -- with-afs, and turn on AFSTokenPassing on both sides (it is on by default). Then, if you have Kerberos-4 and AFS credentials when you log in via SSH, they are automatically transferred to the SSH server, permitting sshd access to your home directory to perform public-key or trusted-host authentication. If you're not using OpenSSH, you might have trouble using SSH in an AFS environment. Patches for SSH1 are available from various sources on the Internet adding the same AFS forwarding features, though we haven't had the opportunity to test them.
For example, Dug Song's ssh-afs patch; see http://www.monkey.org/~dugsong/ssh-afs.
Copyright © 2002 O'Reilly & Associates. All rights reserved.