This is a discussion on Re: How necessary is SSH_AUTH_SOCK? - openssh ; --3V7upXqbjpZ4EhLz Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline On Sun, Oct 01, 2006 at 09:38:56AM -0500, Steven Elliott wrote: > On Fri, 2006-09-29 at 11:11 +0200, Markus Friedl wrote: > > On Thu, Sep 28, 2006 at 12:17:17AM -0500, Steven Elliott wrote: ...
Content-Type: text/plain; charset=iso-8859-1
On Sun, Oct 01, 2006 at 09:38:56AM -0500, Steven Elliott wrote:
> On Fri, 2006-09-29 at 11:11 +0200, Markus Friedl wrote:
> > On Thu, Sep 28, 2006 at 12:17:17AM -0500, Steven Elliott wrote:
> > > So my question is - Why doesn't ssh-agent default the location of the
> > > socket file to some well known fixed secure location such
> > > $HOME/.ssh/agent?
> > $HOME might be on a nfs server, so -a $HOME/.ssh/agent
> > is not the default.
> How is having the socket file on an NFS server a problem? I know that
> other applications do it, such as evolution / spamd:
On most platforms, this is a gigantic mistake, particularly if the
data is or could be sensitive (as is the case with authentication
credentials provided by ssh-agent). There are at least two problems
that I can think of off the top of my head:
1. In general, NFS does not encrypt the data that goes over the wire.
Thus authentication data supplied via the socket can be sniffed by
virtually anyone with physical access to the network, unless the
network admins go through rather a lot of pain to make it
difficult. Most simply do not. [Yes, switched networks CAN be
sniffed too. It's harder, but very possible, and really not that
much harder if you know/have access to the right tools to do it.]
2. In a lot of computing environments, people are allowed to have the
root password to their individual workstation. This is a mess in
an NFS environment, as it means anyone can read any files which are
exported to their machine, with the sole exception of any exported
files owned by root. So again, this would grant anyone and
everyone the ability to get your authentication credentials from
If you're not using Kerberized NFS (and as yet odds are you aren't),
NFS should generally be assumed to be insecure for sensitive data.
With some pain it can be more secure (i.e. access controls on all your
switches, and making sure no one has the root password to any machine
which gets NFS mounts, per-user exports to user-specific machines,
etc.), but I've yet to see a single environment that does all of
what's needed to make it reasonably secure, simply because it's a
monumental pain to set it up and maintain it.
Also, I believe there are some nework filesystems which don't support
named sockets (AFS I believe, though I may be mistaken... CIFS? I
don't know but I'd guess not)... If the environment uses such
filesystems for home directories, it simply won't work at all. The
best place to put such files is generally in a directory in /tmp which
is owned by the user and set to 700 permissions, but the application
must still ensure that the directory tree has appropriate permissions
to prevent the removal or renaming of files leading up to that point
in the file system heirarchy, or else a malicious user could
potentially still replace the file with one they have access to.
Derek D. Martin
GPG Key ID: 0x81CFE75D
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
-----END PGP SIGNATURE-----