Try ssh -Y

Any reason you don't want to use the -Y flag instead of the -X flag?

Quite simply, the difference between -X and -Y is that -Y enables trusted X11 forwarding.

BEWARE (tired of reading incomplete answers which lead to security flaw)

1. using ssh -Y means here having fake xauth information which is bad!

2. ssh -X should work since XQuartz, once enabled, uses xauth. The only problem is that ssh is looking for xauth in /usr/X11R6/bin and on macos with XQuartz it is in /opt/X11/bin

Secure solving:

1. Enable the first option in Security tab of preferences (Cmd-,) which enables authenticated connections

2. add the following to $HOME/.ssh/config

   XAuthLocation /opt/X11/bin/xauth

3. ssh -X you_server works in a secure maner

If you're coming here in 2015: even if everything else is set up properly, this can also happen on Mac OS X 10.10 Yosemite, when using ssh -X and running an XQuartz version <= 2.7.7. The root cause is X11 display sockets getting written outside of the xauth search path: issue #2068 in the XQuartz tracker.

Edit: A fixed XQuartz has since been released at the new homepage, xquartz.org, and installing the latest version from there (currently 2.7.9) will work around the issue.

If you get the same message even when using -Y, the xauth program might be missing on the server. On Debian-like systems, you need the xauth package. On RedHat-like systems, you need the xorg-x11-xauth package.

"Untrusted" in this context means you don't trust the connection. SSH will use additional security measures to try to make X11 forwarding safer. "Trusted" means you are entirely confident that no on on the remote host will get access to your Xauth data and use it to monitor your keystrokes for instance.

This terminology actually confused me for years. I thought "Trusted" connections were safer. But actually it's an option you're supposed to use in situations where the connection IS trustworthy and you want to run stuff without extra security measures getting in your way. "Untrusted" is the one that makes it (somewhat) safer to deal with an untrusted remote host.

An "Untrusted" connection attempts to limit what a black hat could do to you by engaging the X11 security extension and disabling other extensions that you (hopefully) don't need. This is probably why RandR is disabled with -X. Do you need to be able to rotate your X display from the remote host?

It's also important to note that "untrusted" X11 forwarding turns off after a certain amount of time to keep you from accidentally leaving it on. New attempts to open windows will just fail after that. That bit me several times before I read enough docs to understand what was happening.

Rule out server-side problems

First, you should rule out any server-side problems. Are you able to ssh -X from any other host successfully? Does ssh -Y work while ssh -X doesn't? In either case, assume ssh + X11 is set up correctly on your server and move on to the next section.

If you aren't in a position to check that (you have but your one laptop running X11, say), you can ssh from the server to itself using a fake session:

1. export DISPLAY=:44 # (Bourne shell) or
   setenv DISPLAY :44 # (csh / tcsh)
2. xauth add $DISPLAY MIT-MAGIC-COOKIE-1 1234 # Bogus cookie just for this test
3. ssh -X localhost env |grep DISPLAY

Expected result: there should be a DISPLAY variable set on the remote end of the ssh-to-self session. If you get no result, your server is likely mis-configured (e.g. the X11 libraries and/or the xauth command could be missing; or the sshd configuration could be set to deny X11 access)

On Mac: check that Xquartz is up-to-date

As per Will Angley's answer

Examine ssh -vv -X output

The error message you cite is a symptom that can have many causes. Try again with ssh -X -vv remotehost, which should give you additional clues as to why the X11 tunnel setup failed.

Do you see the following message appearing?

debug1: No xauth program.

1. Take note of where on your client system, the xauth command resides:

   which xauth

2. Add the following at the very end of your ~/.ssh/config (and add a comment to remind yourself to keep it there in the future):

   Host *
       XAuthLocation /opt/X11/bin/xauth
   

   Adjust this path as per findings of step 1 — Credits to Jan-Willem Arnold

I don't have a setup that can exhibit this behavior, so this is a shot in the dark:

The warning might be suppressed if you set ForwardX11Trusted to "no" for hosts that give this warning. You can place this in either ~/.ssh/config or /etc/ssh/ssh_config, and you can make the option specific to a particular host by including Host <hostname> on the line above. the <hostname> component matches what you type on the command line (not the resolved hostname), and it can include wildcards.

If installing xauth does not work right, one particularly annoying case could be a corrupted .Xauthority file. This particular case allowed some X clients to work, but not others with a greater tendency to fail with newer displays. Removing and recreating the .Xauthority file can solve that problem.

As has already been explained above, the following worked for me:

Edit ~/.ssh/config to add the lines

Host *
    XAuthLocation /opt/X11/bin/xauth

and now ssh -X hostname works (XQuartz 2.7.11, macOS 10.4 Mojave)

Using XQuartz 2.7.11 on MacOS Catalina, I had to update my /etc/ssh/ssh_config file and add XAuthLocation /opt/X11/bin/xauth after Host * for ssh -X to work