[SOLVED] Xserver in fedora 17, displaying from remote server.

mmcc0912 · 02-06-2013, 11:05 AM

The only setting for display is rc.local, this is for the display manager for oracle to match and be happy. mocha software in win is default, just listens, installed it out of necessity to a VM.

I read that Xserver listens in the 600x range, the mocha is 6000 on the win box. But no listening with fedora. That's what I believe is the issue, the fedora listening for connections. I can send display to another system from this and other servers, if it's the win box.

Completely unedited, can display xclock to the win box but not fedora by telling it where to send it.

Code:

[mmcc0912@desktop scripts]$ ssh root@oraapps1-test.myorthofix.com
root@oraapps1-test.myorthofix.com's password: 
Last login: Wed Feb  6 10:49:15 2013 from 10.10.10.208
[root@oraapps1-test ~]# 
[root@oraapps1-test ~]# echo $DISPLAY
localhost:0.0
[root@oraapps1-test ~]# 
[root@oraapps1-test ~]# export DISPLAY=10.51.1.63:0.0
[root@oraapps1-test ~]# xclock &
[1] 15715
[root@oraapps1-test ~]# 
[1]+  Done                    xclock
[root@oraapps1-test ~]# 
[root@oraapps1-test ~]# 
[root@oraapps1-test ~]# 
[root@oraapps1-test ~]# export DISPLAY=10.10.10.208:0.0
[root@oraapps1-test ~]# xclock &
[1] 15792
[root@oraapps1-test ~]# Error: Can't open display: 10.10.10.208:0.0

[1]+  Exit 1                  xclock
[root@oraapps1-test ~]# 
[root@oraapps1-test ~]# 
[root@oraapps1-test ~]# 
[root@oraapps1-test ~]# exit
logout

Connection to oraapps1-test.myorthofix.com closed.
[mmcc0912@desktop scripts]$ netstat -an |grep ':600'
[mmcc0912@desktop scripts]$ 
[mmcc0912@desktop scripts]$ ifconfig
em1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.10.10.208  netmask 255.255.255.0  broadcast 10.10.10.255
        inet6 fe80::baac:6fff:fe9f:79c9  prefixlen 64  scopeid 0x20<link>
        ether b8:ac:6f:9f:79:c9  txqueuelen 1000  (Ethernet)
        RX packets 60841041  bytes 11384050020 (10.6 GiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 91429107  bytes 104445234428 (97.2 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 21  memory 0xf7fe0000-f8000000  

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 16436
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 0  (Local Loopback)
        RX packets 1654729  bytes 862840213 (822.8 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1654729  bytes 862840213 (822.8 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

[mmcc0912@desktop scripts]$

suicidaleggroll · 02-06-2013, 11:17 AM

That's not how you use X forwarding through SSH. You don't "push" the display to some random IP with a listening X server. As jpollard said:

Quote:

Originally Posted by jpollard

sshd creates the X forwarding by opening a TCP port (6000+offset specified from sshd config file+increment to find unused port). That port is then passed to the X clients using the DISPLAY environment variable (value is localhost:<port-6000>.0). Any other value causes an access failure due to improper credentials.

DISPLAY should be set automatically when you run ssh -X (or ssh -Y) to localhost:<port-6000>.0. You do not force it to anything. You mentioned that rc.local is modifying display, how so? An example of how it should look:

Code:

$ netstat -an | grep ':600'
$ \ssh -X server7
$ echo $DISPLAY
localhost:131.0
$ emacs &
[1] 2958
$

And how you're using it:

Code:

$ ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 00:30:48:D4:A4:58  
          inet addr:192.168.1.102  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::230:48ff:fed4:a458/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:11327048 errors:0 dropped:0 overruns:0 frame:0
          TX packets:9973211 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:6765478122 (6.3 GiB)  TX bytes:4906091693 (4.5 GiB)
          Interrupt:16 Memory:c0100000-c0120000 

$ \ssh -X server7
$ echo $DISPLAY
localhost:131.0
$ export DISPLAY=192.168.1.102:0.0
$ xemacs

Gui error: X server not responding
, "192.168.1.102:0.0"
$

Can you get it to work if you ssh to yourself?

Code:

$ echo $DISPLAY
:0.0
$ \ssh -X localhost
$ echo $DISPLAY
localhost:10.0
$ xemacs &
[1] 1903
$

mmcc0912 · 02-07-2013, 09:49 AM

Maybe this is one thing that I'm trying to say, I'm not trying to use ssh as the vehicle. All the years (few beit) that I've been in Linux, I've always connected via ssh, exported display to a host (windows w/ X software) and sent the display back to myself. I wanted to ask at large how to use the same functionality within Linux to send the display back, it was the original desire to continue working it the same way.

Yes, I can ssh to localhost and run, but I have the desire to get out of windows. I can make a Linux node display to windows host, but not back to another Linux host.

suicidaleggroll · 02-07-2013, 09:59 AM

Well unfortunately you've been doing it wrong. The way you've been working is insecure, error-prone, labor-intensive, and only works when connecting between machines on the same local network or when you have a public IP. Perhaps instead of trying to force Linux to do it the wrong way, you should start learning how to do it the right way?

Since the X connection works properly when you ssh to yourself, that means you're using it correctly. So again, the problem comes down to a misconfiguration on the server.

jpollard · 02-07-2013, 08:59 PM

Besides being insecure, the configuration and use of the display manager disable TCP connections because it is insecure.

X by default doesn't use TCP.

And until the use of encrypted TCP based X connections is restored (I believe it is being worked on), X will remain insecure over TCP. It passes the connection authorization in plaintext, and the usual authorization is just an long password, so it is as bad as using unencrypted passwords anywhere else.

mmcc0912 · 02-08-2013, 10:40 AM

OK, well, I didn't know that it was insecure. I can see with public access how that can be, yes. But it's all internal. It's worked well for years, just exporting out to send the display out if you needed a GUI on a run-level 3 box. Nothing much really to it.

Yes, if there is a better way, I'm all for it. I'm not seasoned on Linux, converted win guy... But I do learn regularly.

Thanks everyone for banging me through it. It is greatly appreciated.