Bug 101124 - No remote display permission even after using xhost +
Summary: No remote display permission even after using xhost +
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: XFree86
Version: 9
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Mike A. Harris
QA Contact: David Lawrence
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-07-29 14:31 UTC by Need Real Name
Modified: 2007-04-18 16:56 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2003-08-01 10:02:13 UTC
Embargoed:


Attachments (Terms of Use)

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


Note You need to log in before you can comment on or make changes to this bug.