The Linux Administration group is for the discussion of technical issues technical issues that arise during the administration of Linux systems, including maintaining the operating system and supporting end-user applications.

The first, and obvious possibility is that you have XWindows configured badly.
The error message complains about video problems, so you have your Xwindows
display config file either destroyed, or with invalid entries. IF you have a display
card, see if it's loose in it's motherboard connection, or even it's cable to the
display. Otherwise, you probably have an invalid display setting, that your
video hardware doesn't support. Boot to single user mode, and set the
display to 1024 x 768, or another generic setting both your card, and your
display support.

astroboy, i think you need to append your statement, I use runlevel 3 all
the time and xwindows remotely... if he is doing a remote session then
runlevel has little to do with remote sessions and xwin.

did you start ssh with the -x option
ssh -x
if you can ssh -x then you can start your GUI apps without running an entire desktop environment
If you do need a full desktop environment, setup XDM up for remote access, or even VNC

I agree, but Selva starts with what appears to be attempt to start XServer on the remote system. Perhaps, that was intentional.

The concept of XServer is easily confused. I explain it (to my boss) this way:
a server provides a service to a client
the service provided by an XServer is to provide the graphical video interface
in the simplest case that service is provided locally
therefore your workstation is both a server and a client for that service

perhaps we should leave remote desktops and wonders like nx for another thread

Thanks Selva Prakash,
I see that xcalc is not available in centos for some reason.
At least we know that, so far, a connection has been established.
We may as well skip to the desktop environment since poking around for windows managers may be fruitless
Next run

gnome-session

NOTE: gnome over SSH tends to not exit cleanly. After your gnome session is over run the following to locate and kill / pkill whatever is left

ps -aux | grep gomer

If you don't have Gnome installed centos with KDE use this instead

startkde

You will find that KDE is better under SSH. You may want to consider installing it if Gnome becomes a problem.

I agree. What I'm attempting is to get the user to a desktop environment without them trying to use startx (should only be used locally)
I believe gnome is the default desktop environment for centos. startxfce is for the xfce desktop environment.

# This is the sshd server system-wide configuration file. See
# sshd_config(5) for more information.

# This sshd was compiled with PATH=/usr/local/bin:/bin:/usr/bin

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented. Uncommented options change a
# default value.

# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#RhostsRSAAuthentication no
# similar for protocol version 2
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# RhostsRSAAuthentication and HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes

# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication mechanism.
# Depending on your PAM configuration, this may bypass the setting of
# PasswordAuthentication, PermitEmptyPasswords, and
# "PermitRootLogin without-password". If you just want the PAM account and
# session checks to run without PAM authentication, then enable this but set
# ChallengeResponseAuthentication=no
#UsePAM no
UsePAM yes

X over SSH solves some of the problems inherent to classic X networking.
For example, SSH can tunnel X11 traffic through firewalls and NAT, and the
X configuration for the session is taken care of automatically. It will
also handle compression for low-bandwidth links.

SSH and X together make it easy to run GUI apps over the network between two
hosts. The combination takes care of NAT issues, firewall issues,
encryption, and authentication.

Thanks krystynah,
I understand the hows and whys of X over SSH. I was wondering how

the Intel driver cannot find kernel modesetting.

and updating the kernel have anything to do with X over SSH.
The local hardware driver should not come in to play in an X over SSH session as X11 is forwarded to the remote client.
Perhaps I'm missing something. Maybe if you can re-read this entire thread, you can point to our mistakes.

Next - when the permission not help : Let us focus on error:
XIO: fatal IO error 104 (Connection reset by peer) on X server ":0.0"
after 0 requests (0 known processed) with 0 events remaining.
Couldn't get a file descriptor referring to the console

xset and xsetroot failed to open display on "207.114.247.155:0" (the OP's local machine)

Consider that error and the following

Connecting through Windows XP in telnet & some other Secure Application. via SSH

It looks like the problem is not with the Centos remote system but the local XP box.
The OP may not have an X server such as Xming or Cygwin/X installed or configured properly.
startkde returns errors opening the display on the OP's local machine.

Hopefully we will hear back after the red hearing of hardware and permissions errors are looked at.

I had assumed he was connecting from another linux machine and had X running

I had made the same assumption. When I saw

xset: unable to open display "207.114.247.155:0"

I realized that the OP had never specified what OS they were connecting from. That's when a tiny light bulb went off. It's these type of assumptions that always bite me in the end.
The discussion about tty0, xorg.xconf, permissions, drivers, etc were all irrelevant responses to trying to run startx from SSH and I think they just ended up confusing the OP.

Copyright 1998-2015 Ziff Davis, LLC (Toolbox.com). All rights reserved. All product names are trademarks of their respective companies. Toolbox.com is not
affiliated with or endorsed by any company listed at this site.