allow X11 remote connection

[7280]

Hi,
my system is running Suse Linux 10.1.
I want to use my system to export a remote display.
I have disabled suse firewall:
linux:~ # /sbin/SuSEfirewall2 status
SuSEfirewall2: Warning: ip6tables does not support state matching. Extended IPv6 support disabled.
SuSEfirewall2: SuSEfirewall2 not active
I have added also these entries in /etc/sysconfig/displaymanager:
DISPLAYMANAGER_REMOTE_ACCESS="yes"
DISPLAYMANAGER_XSERVER_TCP_PORT_6000_OPEN="yes"
Then I restarted X11.
If I run nmap on my system I see:
linux:~ # nmap localhost

Starting Nmap 4.00 (

http://www.insecure.org/nmap/

) at 2006-07-18 16:33 CEST
Interesting ports on localhost (127.0.0.1):
(The 1669 ports scanned but not shown below are in state: closed)
PORT STATE SERVICE
22/tcp open ssh
631/tcp open ipp
6000/tcp open X11

Nmap finished: 1 IP address (1 host up) scanned in 0.190 seconds

But if I run nmap from another server I don't see X11.
And if I try to run any x application remotely, eg. xclock, I recieve error:
Error: Can't open display: ip
Of course on my system I run xhost +

Please advice, thanks
Tarek

 

[pansophic]

The first thing that I would do is to shut down the firewall and rerun your NMAP scan, just to verify that the Xserver is actually listening on the network interface and not just localhost.

Also, I would never use "xhost +" as it allows anyone to log onto your machine as root. If you need to connect to your machine from anywhere, then at least tunnel through ssh or a VPN where you can provide some form of authentication. Since it would appear that you are getting in through ssh anyway, why not tunnel it and keep port 6000 closed on your firewall?

Next, what is the DISPLAY environment variable set to when you log in remotely? You need it set to DISPLAY=remote_host:0 or whichever display on that host you are trying to connect with. You can display the variable by using "echo $DISPLAY" and you can set it using "export DISPLAY=remote_host:0" in your shell. If ssh is set up to allow tunneling of X, then the display variable is normally set on login.


pansophic

 

[7280]

Hi,
thanks for your response.
As you can see from output of command "SuSEfirewall2 status" firewall is down but I still can't see port 6000 from remote host.
DISPLAY variable is already set correctly on remote host.
I did xhost+ just to be sure that this was not the problem. Usually I use xhost+ remotehost.

On my server I have two nic, but only one is configured.
If I issue ifconfig -a I see also the other nic but it's down. Can this be the problem?

Thanks,
Tarek

 

[pansophic]

There shouldn't be a problem with the other NIC being down. If that was the problem, you couldn't ssh into the computer either (it would be a routing issue).

What does the output of "netstat -ln" and "lsof -i" look like? Does the system think that the Xserver is listening on all interfaces? Or only loopback (which is correct in most distributions).

Is there a reason that you are reluctant to simply tunnel over ssh? It is the safest method of remoting an Xsession. Otherwise all of your data passes in the clear. All you have to do is go to your /etc/ssh/sshd_config and uncomment or add the lines "X11Forwarding yes" and "X11DisplayOffset 10" and restart sshd. You have to allow X tunneling on your client as well if you are using something like putty to remote the display, but I believe all of the linux distros enable tunneling on the client by default.


pansophic

 

[7280]

Hi,
netstat -ln shows for Active Internet connections:
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 0.0.0.0:6000 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:631 0.0.0.0:* LISTEN
tcp 0 0 :::6000 :::* LISTEN
tcp 0 0 :::22 :::* LISTEN

lsof -i shows for listening services:
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
sshd 2168 root 3u IPv6 6585 TCP *:ssh (LISTEN)
X 2504 root 1u IPv6 7404 TCP *:6000 (LISTEN)
X 2504 root 3u IPv4 7405 TCP *:6000 (LISTEN)
cupsd 2508 lp 0r IPv4 7926 TCP *:ipp (LISTEN)

X11Forwarding is already set to yes in /etc/ssh/sshd_config.

Thanks again

 

[pansophic]

Those both indicate that the system is listening on all interfaces, so there must be something else blocking the requests. The only things that I can think of off hand would be a firewall (either on the scanning or scanned machine, or on the network between), a port filtering router between the two machines, or some IPTables/IPChains on the scanning or scanned machines.

If you run ethereal (or tcpdump) during the scan, do you see the requests arriving at the external interface?


pansophic

 

[QatQat]

As Pansophic recommended I would definitely tunnel using ssh, anyway you may need to enable the client as well by modifying ssh_config file and adding

ForwardX11 yes

QatQat

Life is what happens when you are making other plans.