Thank you all for solving this issue for me! Anyone have a command to speed up my work's VPN speed? :-)

I just got bitten by this, but it didn't seem to be the '.' that xauth objected to because using the symlink /tmp/launch-iq6W7f/orgamacosforgeaxquartz:0 didn't fix things; running SSH's raw token generation still yielded:

/usr/X11R6/bin/xauth: (argv):1: bad display name "/tmp/launch-iq6W7f/orgamacosforgeaxquartz:0" in "add" command"

and I still got the failure message from SSH.

Rather than guess what it wanted, I tried the xauth from MacPorts' x11/xauth package. That worked, dots and all:

bash$ touch blahxauthfile
bash$ /opt/X11/bin/xauth -f blahxauthfile generate /tmp/launch-iq6W7f/org.macosforge.xquartz:0 MIT-MAGIC-COOKIE-1 untrusted timeout 1200
bash$

and can be set in .ssh/config using XAuthLocation. Let's hope Lion fixes /usr/X11R6/bin/xauth.

I tried your work-around, and it worked well for me. I'm surprised this isn't more widely known on the web. Many Mac people must be getting the following annoying error messages when trying to do "ssh -X remotehost":

Warning: untrusted X11 forwarding setup failed: xauth key data not generated
Warning: No xauth data; using fake authentication data for X11 forwarding.

My two modifications to your fix were to drop the line that executed "xauth", for the reasons that James Gilbert said, and that I put it in ~/.bash_profile, which I think is the more standard place to modify environment variables (at least that's how my Mac bash environment is set up). Your approach of using a logical link seemed less-intrusive and safer than moving the file. The resulting section I added to ~/.bash_profile is:

if [ -e "$DISPLAY" ]; then
DISPDIR=$(dirname $DISPLAY)
NEWDISP="${DISPDIR}/:0"
if [ ! -e "$NEWDISP" ]; then
ln -s "$DISPLAY" "$NEWDISP"
fi
export DISPLAY="$NEWDISP"
fi

Your procedure provides a workaround to an acknowledged bug in XQuartz, see http://xquartz.macosforge.org/trac/ticket/459, which has been fixed as of XQuartz v. 2.6.0, but Apple's Software Update has not yet pushed out these bug fixes as of the current time (even though this bug was fixed 7 months ago).

The "untrusted X11 forwarding" is apparently designed to try to prevent keyloggers from stealing passwords, etc. However, one should be aware that there are statements on the web that this may give a false sense of security and is only slightly more secure than "trusted X11 forwarding", see for example:

http://cygwin.com/ml/cygwin-xfree/2008-11/msg00154.html
http://dailypackage.fedorabook.com/index.php?/archives/48-Wednesday-Why-Trusted-and-Untrusted-X11-Forwarding-with-SSH.html

I do not understand these issues well enough to know if they are out of date or not. The official x.org web site has some statements about "ongoing" work to improve security:

http://www.x.org/wiki/Development/Documentation/Security

Thanks for this post. Having read it, I decided to do it slightly differently. I put this in my ~/.bash_profile (which is where I modify any environment variables):

if [ -e "$DISPLAY" ]; then
dispdir=`dirname $DISPLAY`
dispfile=`basename $DISPLAY`
if [ "$dispfile" = "org.macosforge.xquartz:0" ]; then
dispnew="$dispdir/:0"
mv "$DISPLAY" "$dispnew" && export DISPLAY="$dispnew"
fi
fi

So I rename the file, rather than making a symbolic link. I don't run xauth, because ssh appears to do that for me when I connect to a host with X11Forward set, and because when xauth runs it launches my X11, so I don't want that happening.

Hey: if it is or not a good idea, I have not enough knowledge to tell you, but it worked perfectly for me!

Thanks :-)