X11UseLocalhost no
X11Forwarding yes.
Setting the X display to the user node defeats the whole purpose of
using ssh since your displaylist instructions will be sent unencrypted.
Leave X11UseLocalhost on rather than turning it off.
The user should ssh in with the -Y option or the equivalent in their
ssh_config. Do not explicitly set DISPLAY yourself. This gives the
session a DISPLAY=localhost:10.0 that is forwarded securely through the
ssh pipe.
If I understand your example correctly, you're trying to do this:
machine --- ssh ---> machine1
<--- DISPLAY='machine:10.0'
X displays directly to 'machine' unencrypted, not through ssh - INSECURE.
What you want is:
machine <--- ssh ---> machine1 DISPLAY='localhost:10.0'
sends X display through localhost, forwarded to user via ssh, encrypted
- SECURE.
No idea why the anomaly with a second session running. It will go away
when you're correctly set up.
1) User ssh's into remote machine (machine1.company.com) which is
running the new version. Tries to run an X process, say xclock. User
is told:
Error: Can't open display: machine.company.com:10.0
On this second session the client has been handed
the same display (machine1.company.com:10.0) as the first session.
Seems like you are talking two different displays here, one on "machine"
and one on "machine1". If they are given 'machine1' as the X server
then X forwarding is probably taking care of the rest. Your problem
comes when 'machine' (the user node) is the X server, correct? It's a
red herring, since you should use X forwarding via the ssh connection
without explicitly setting DISPLAY anyway.
-Lew
--
redhat-list mailing list
unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/redhat-list
