Don't set the display on the remote side. By using the -Y parameter on SSH, it will set up a listener on the (remote)local side that gets tunneled back to the local side.

You should be able to do this:

local$ ssh -Y user@remote
remote$ xlogo

...and the xlogo will pop up.

Edit: this assumes that the display is set up on the local system first, ie:

local$ xlogo

...should work before you perform the ssh, as ssh just plugs the forward back to whatever the originating session thinks is the correct display. This is useful, since you can carry your display through multiple ssh sessions:

local$ ssh remote
remote$ ssh further
further$ xlogo

...should work.

Are you certain that the user account you're attempting to access is correctly configured? If you log in as root on the system, can you su to the user account?

# su - username

What do you see in your logs after a failed connection attempt? On many systems, sshd will log to something /var/log/secure or /var/log/auth.log. Also, I note that you have PasswordAuthentication enabled but ChallengeResponseAuthentication disabled. Do you see the same behavior if you enable ChallengeResponseAuthentication?

Here are some general diagnostic steps to use when you have ssh problems:

• Enable verbose diagnostics in ssh:

  ssh -v host.example.com
  

  This will cause the client to output a variety of diagnostic messages as it negotiates the connection. This will often provide a clue to the problem.

• Run the server in debug mode.

  On your server, stop sshd, then run it from the command line like this:

  /usr/sbin/sshd -d
  

  This will produce verbose debug logging on stderr that will very often contain useful information.

If neither of these helps you figure out what's going on, would you add the output to your question?