I have another answer to the question that plagued me before I figure out the issue. The issue is a bug in Fedora OS and it's derivatives, as I later figured out. If the issue isn't as indicated by the accepted answer, and/or you're not on Fedora, RedHat, Korora, etc, then this won't help you.
The Problem
As user slm said, running strace will give you an indication of the issue, but in this particular bug's case, the output is different:
$ strace xauth list
...
stat64("/home/USER/.Xauthority-c", 0xbff23280) = -1 ENOENT (No such file or directory)
open("/home/USER/.Xauthority-c", O_WRONLY|O_CREAT|O_EXCL, 0600) = -1 EACCES (Permission denied)
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
nanosleep({2, 0}, 0xbff232c8) = 0
open("/home/USER/.Xauthority-c", O_WRONLY|O_CREAT|O_EXCL, 0600) = -1 EACCES (Permission denied)
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
nanosleep({2, 0}, 0xbff232c8) = 0
open("/home/USER/.Xauthority-c", O_WRONLY|O_CREAT|O_EXCL, 0600) = -1 EACCES (Permission denied)
...
To be clear, this is stating that EACCES return code, which is permission denied. This is different than user slm's problem, where he had the EEXIST return code, which means File exists. So, for the EACCES return code, obviously the first thing you check is: are my home permissions set up so I am able to write to my home directory? You should verify you have the write flag on your home directory for your own user first. If you do, then you might be a victim of the bug described below.
The Bug
Through a couple google searches I was finally able to find somebody with a similar problem, and it led me to Fedora bug report. For those of you that care to read about it: https://bugzilla.redhat.com/show_bug.cgi?id=772992
The Workaround
The workaround to the issue:
#verify you're not crazy
$ xauth list
/usr/bin/xauth: timeout in locking authority file /home/USER/.Xauthority
#use restorecon to reset it all
$ /sbin/restorecon -v -v /home/USER/.Xauthority
$ /sbin/restorecon -v -v -R /home/USER/
#log out of the remote system
$ exit
When you SSH back in, it should be fine at this point and you should be able to successfully transfer your X-session again.
EDIT (and other alternative workarounds):
Just to be as complete as possible, other users did state in the bug report that the fix above did not work for them - it happened to work for me. Another attempt to work around the problem was (I did not verify this workaround personally):
# setsebool -P use_nfs_home_dirs 1
Another person mentions something about GDM, which I have zero knowledge of. If that pertains to you I recommend reading his post in BugZilla and seeing if his comment means anything to you.
