weird ssh or X problem

Lew Bloch conrad at lewscanon.com
Sun Jul 24 21:14:06 UTC 2005


>
>
>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




More information about the redhat-list mailing list