 | |  |
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:
- Your home directory needs to be safe from tampering.
- SSH must have access to your home directory.
10.7.1. NFS Security Risks
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 SSH2, which has the
UserConfigDirectory option 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 SSH1 or OpenSSH, but as they lack 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 IgnoreRhosts option. 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.
10.7.2. NFS Access Problems
Another 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 Problems
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.
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, [129] though we haven't had the opportunity to test them.
|  | | | 10.6. Client Configuration |  | 10.8. Summary |
|
|
