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:
Discover the uid, and create an account with that uid on a laptop running Unix.
Connect that machine to the network, borrowing the IP address of a trusted host.
Issue a mount command, su to the account with the uid, and start rifling through the files.
At this point, an intruder can easily add another public key to authorized_keys, and the account is wide open. The moral is that when designing a system, keep in mind that the security of SSH is no stronger than that of the home directories involved. You need at least to be aware of the trade-off between security and convenience involved here. If you are using an insecure NFS and want to avoid this weakness, you can:
Use Tectia, which has the
UserConfigDirectoryoption to place the per-user SSH configuration files, normally in ~/.ssh2, elsewhere—say, in /var/ssh/ <username>. You can still set the permissions so their owners can control them, but they won’t be shared via NFS and thus not vulnerable. You can do the same with OpenSSH, but as it lacks such a configuration option, you need to edit the source code.Turn off hostbased authentication, since the ~/.shosts control file is vulnerable, and you can’t change its location. Or, if you want to use hostbased authentication, set the
IgnoreRhostsoption. This causes sshd to ignore ~/.shosts, relying instead solely on the systemwide /etc/shosts.equiv file.If you are truly paranoid, disable swapping on your Unix machine. Otherwise, sensitive information such as server, host, and user keys, or passwords, may be written to disk as part of the normal operation of the Unix virtual memory system (should the running sshd be swapped out to disk). Someone with root access (and a lot of knowledge and luck) could read the swap partition and tease this information out of the mess there—though it’s a difficult feat. Another option is to use an operating system that encrypts swap pages on disk, such as OpenBSD.
Another problem that can arise with SSH and NFS is one of access rights. With the public-key or hostbased 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 that 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. Current versions of Tectia and OpenSSH handle this correctly, but you might run into older versions that do not. 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 toward your files and the other users on the machines where your home directory is accessible.
The 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.
AFS uses its own authentication system; access to remote files is controlled by possession of an appropriate AFS token. There are no uid-switching games root can play; sshd must have the right AFS token in order to access your home directory. If you were logged into that machine, of course, you could use the usual AFS klog command to authenticate to AFS. However, sshd needs it before you’ve logged in, so there’s a bit of a quandary.
There is one solution available, though, involving Kerberos. If Kerberos is available, AFS will usually be configured so that AFS tokens can be obtained via Kerberos, bringing AFS into the Kerberos single-signon universe. If you have protocol-2 Kerberos support enabled with ticket forwarding [11.5.2.2], then OpenSSH can use your forwarded credentials to automatically obtain the needed AFS token:
# ~/.ssh/config
GSSAPIAuthentication yes
GSSAPIDelegateCredentials yes
KerberosGetAFSToken yesNote that the older OpenSSH Kerberos-4 mechanism for this,
controlled by the keyword AFSTokenPassing, is no longer available. The
current support is only for Kerberos-5 and GSSAPI.