Bug 101124

Summary: No remote display permission even after using xhost +
Product: [Retired] Red Hat Linux Reporter: Need Real Name <brackney>
Component: XFree86Assignee: Mike A. Harris <mharris>
Status: CLOSED NOTABUG QA Contact: David Lawrence <dkl>
Severity: medium Docs Contact:
Priority: medium    
Version: 9   
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2003-08-01 10:02:13 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Need Real Name 2003-07-29 14:31:36 UTC
Description of problem:  I run some headless machines on my LAN and typically 
telnet or ssh to them and redirect the DISPLAY back to my desktop.  This always 
worked fine with RH7.3, but apparently doesn't after my recent RH9 upgrade.


Version-Release number of selected component (if applicable):


How reproducible: Always


Steps to Reproduce:
1. xhost + on my desktop machine (192.168.0.3)
2. telnet to the remote machine (192.168.0.5)
3. export DISPLAY='192.168.0.3:0.0'
4. try opening an X-app on my desktop - e.g. xclock
5. get "Error: Can't open display: 192.168.0.3:0.0"
6. xclock -display 192.168.0.3:0.0 fails on 192.168.0.5 but works on 192.168.0.3

    
Actual results:
Get X permission error

Expected results:
X window should open on my desktop

Additional info:
I have also try explicitly granting the remote machine in question X permissions 
using xhost instead of the much more permissive xhost + but with the same 
results.

Comment 1 Mike A. Harris 2003-08-01 10:02:13 UTC
By default in Red Hat Linux, sshd is configured to permit X11 forwarding between
hosts.  You just ssh to a host and run an X11 application with no configuration
required.  No need to use xhost or xauth at all.

TCP is also disabled by default (and always has been).  I don't see any reason
why you'd want to forgo the X11 forwarding built into ssh and do things the
ancient way, but if you want to you can reconfigure things to do so.  For
assistance with that, ask on one of our mailing lists, but I strongly recommend
just using native default X11 forwarding as it is completely painless, and just
works out of the box, plus all of your traffic is encrypted for free.

Closing as NOTABUG