|
|
Home | Switchboard | Unix Administration | Red Hat | TCP/IP Networks | Neoliberalism | Toxic Managers |
| (slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and bastardization of classic Unix | |||||||
| News | X Window System | Recommended Links | vnc | "Can't open display" Error |
| Xdefaults | Xhost | Using xauth | Humor | Etc |
|
|
|
|
Exporting display in X11 involves two distinct operations (X11 ports should be open if firewall is running. when troubleshooting disable firewall to exclude any interference from it):
For example,
if you are logged to remote server
export $DISPLAY=home.yourdomain.com:0
Allowing server to accept X11 session from the client. This part is accomplished by using xhost + or xhost <ip-from-which X11 session comes(client). On RHEL you need to jump additional hoops.
ATTENTION:
In RHEL by default X11 is enabled only for localhost.
To be able to connections from the external box you need to edit the file /etc/gdm/custom.conf. The default setting for RHEL is
[security] DisallowTCP=yeswhich should be changed to false
To enable XDMCP that some users need you need to enable it.
[xdmcp] Enable=true
After that restart gdm using command
gdm-restart
or restart X11 using the command
init 3 && init 5
If in addition you want to provide ability to log as root you need security section as following
[security] DisallowTCP=false AllowRemoteRoot=true
But please do it only on temp basis. Here is an example# GDM configuration storage [daemon] [security] DisallowTCP=false AllowRemoteRoot=true [xdmcp] Enable=true [greeter] [chooser] [debug]
The environment variable DISPLAY is of particular importance in X windows because it tells the computer on which machine the graphics is to be displayed.
You should look at the current setting of DISPLAY while you are logged in:
echo $DISPLAY
:0.0
This means that your machine is displaying on its own screen. The command uses different connection protocol then in case localhost:0.0.
The string 0.0 identifies a server number and an optional screen number. In most cases, both of these are zero.
You need to allow X11 server to accept remote sessions. The simplest (and the most unsecure) was to accomplish that is by using " xhost + ". Generally this directive should be limited to troubleshooting and test mode.
NOTE: xhost + allows anyone to connect to this Xserver, and is not recommended for security reasons..
If you are lucky then if you launch X application on the client (your remote server remote_server.yourdomain.com), the screen of the application will appear on machineworkstation .yourdomain.com .
You permit that other machines can display on your using the command xhost. This command is can be included in your .profile file on your LINUX home directory. The syntax is xhost machine name. For example:
xhost +workstation.yourdomain.com
Again in test mode you can use "universal opener":
xhost +
You can deny display access by machine
xhost -other.yourdomain.com
See
|
|
Switchboard | ||||
| Latest | |||||
| Past week | |||||
| Past month | |||||
 |
 |
 |
X is network transparent. This means that clients can run on a different machine from the server and communicate with it over the network. Clients use the environment variable DISPLAY to decide which server to connect to. If you are sitting in front of an EE machine and have opened a window onto another EE machine the command xdisp, typed on the remote machine, will set $DISPLAY automatically. On other machines you will have to set it yourself. Csh users should use something like
setenv DISPLAY abraham.ee:0
Bash users should use
export DISPLAY=abraham.ee:0
with abraham replaced by the name of the local machine. NOTE: don't forget the .ee in the display name - from outside the department our machines must be referred to as machinename.ee.
Most X clients also support a -display command line option to tell them which server to use. For example you could type
xman -display abraham.ee:0
X and OpenWindows are set up to automatically allow you access to a server you have started from any machine in the department. Other people will be unable to access the display, even if the client is running on the same machine as the server.
For machines outside the department, access is not automatic. There are two ways to allow access. The secure way is to use rcp to copy ~/.Xauthority to the remote machine. This has to be done every time you start X. A less secure but simpler way is the xhost command. To allow access from castle you would type
xhost +castle
on the local machine.
NOTE: the xhost command allows anyone on castle to open windows on your display, watch what you are doing or even see every key that you type.
If you need to allow someone else access to your display for some reason you should use xhost. This works because xhost authorisation is done on a per-machine basis, rather than the per-user basis that the default MIT MAGIC-COOKIE-1 authorisation uses.
The abilty to run X applications over the network is primarily useful when you want to run an application on a sun4 or castle, either because it is faster or only available for certain architectures, but use a colour display (all of our publically available sun4s are monochrome).
|
|
|
As was previously mentioned, it is possible to run X programs on one computer and display them on another. This is incredibly bandwidth-intensive, so you probably won't want to do this over a modem connection or over very long distances. Additionally, there are security considerations: exporting a display is not a very secure thing to do, since you'll be letting the entire network look at what you're doing. Still, it can be very useful on a local network.
An important thing to note here is the use of the words "client" and "server". When exporting the display, you may become confused as to what's a client and what's a server. We refer to the machine that actually runs the X programs and sends the display information as the "server". The machine that you use to display the remote program is called the "client". When discussing the design of X, this is reversed. The program that displays things is called the "server", while the running program is called the "client". It's not too terribly confusing, but worth pointing out.
For this example, we'll be making use of two computers: golf is a fairly powerful server sitting underneath a desk on one side of a crowded room. It has a lot of RAM and a nice processor in it. In addition, it has lots of X programs on it, but no monitor. On the other side of the room is couch, an old machine with little RAM and not much disk. It is way too weak to run resource-intensive programs like Netscape. couch has two major advantages, though: it has a monitor, and it is sitting right next to the couch so you don't even have to get up to use it. Ideally, you would be able to run Netscape without getting off the couch. Exporting is the answer.
First, log in to couch and start up X. Then open your favorite terminal program (xterm, rxvt, eterm, aterm, or a host of others). The first step to remotely displaying X programs is to set up the client machine so that other machines are allowed to display to the machine. This uses the xhost program to control access. If you are on a secure internal network, you probably don't care who can remotely display programs. In that case, you would just let anyone on the network display:
On the other hand, you might want to do this using machines that are on an insecure network (the Internet, a college network, or anything else that you don't have control over). You certainly don't want just anyone to connect. xhost allows you to be selective about who can display:
Now, only golf.foc (the server mentioned earlier) can display programs to couch. You can see who has access to display programs by running xhost with no arguments:
This is all you have to do to set up the client end of things. The next step is to set up the server so that it knows to display programs somewhere other than the monitor. Since the server doesn't have a monitor on it (and therefore doesn't have X running), it'll need to know where to display.
Setting up the server is not very difficult either. After connecting, you'll need to modify the $DISPLAY environment variable. By default, it will probably not be set to anything. You'll need to set $DISPLAY to the value of the remote host, plus a number that represents which X session to display to. You will almost always have only one X session running, so dealing with that variable shouldn't be an issue.
Here's how the $DISPLAY variable would be set on our example server using Bash as the shell. Other shells would use a different syntax, but the value should be the same.
That's all there is to setting up the server side of things. Now you just stay logged into the server and run X programs from there. All the screen output from the program will get sent across the network to the client machine, even though it's running on a computer across the room.
This would run netscape off the server machine, but since the DISPLAY variable is set to couch, everything will get displayed there. You don't even have to get up to run those big X programs on your old terminal. One important note about this: the server machine will have to have all the X libraries and other support files needed to run the program. However, you won't need an X server or a /etc/XF86Config file, since nothing is getting displayed to the server.
Afterwards, you might want to disable display exporting by removing the server from your client's access control list:
You can see how this a great way to share computing resources. But be careful, you may be the host of many X programs for many remote computers and not even know it
|
|
|
Q: I use telnet from my Linux box at home to use the HP_UX boxes at university. No problems with telnet, but is there a way to get it to export the X display so that I can use tools other than command line ones?
John Hinsley
Short answer: Use ssh instead.
The default for telnet is to preserve a number of environment settings, including TERM, and DISPLAY. (Any recent telnet daemon should also perform some sanitization on these variables to prevent some degenerate values from being propagated through them to a potentially vulnerable program).
So, if you issue a 'set', 'env' or 'printenv' command and look you might find that your DISPLAY variable IS set. However, it's probably set to the wrong thing.
When you run 'startx' on the local system, it sets your DISPLAY variable to something like: DISPLAY=:0.0 X client programs seeing this value under Linux or UNIX will attempt to connect to the X server via a local UNIX domain socket (one of those nodes in the a filesystem whose permissions/type starts with an "s" in a "long" 'ls' output). That works for the local processes talking to the local X server.
However, to start a remote process that needs to talk to your local X server you must set the DISPLAY variable to a hostname and display number. What you need is something like
DISPLAY=123.45.67.85:0.0 or DISPLAY=foo.bar.not:0.0
Programs that are linked against X libraries will automatically search their environment for a DISPLAY value. If it specifies a hostname or IP address, they will attempt to open a TCP connection (Internet domain socket) instead of a local file/node (UNIX domain socket) connection. Specifically they will try to connect to port 6000 for :0.0, and 6001 for ...:1.0, etc. (Incidentally, the .0 in :0.0 or localhost:0.0 refers to a possible display number. Some X servers support multiple displays/monitors, and these address each of the displays as 0.0, 0.1, 1.0, 1.1 etc).
So, one solution is to use the following sort of command (assuming that you are using a Bourne compatible shell like 'bash' which is the Linux default):
DISPLAY=your.local.hostname:0.0 telnet to.your.remote...... this variation of the familiar syntax sets this value for the DISPLAY in the environment of the following command (that is on the same line as the assignment, and NOT separated with one of the normal command delimiters, like the semicolon).
Naturally you'd probably put this into whatever function, alias, or shell script you are using to start these telnet sessions. You could use a more portable syntax like:
DISPLAY=`hostname`:0.0 telnet ...... where the backtick (command substitution) expression is used to fill in the blank. This will allow those shell scripts, etc to adapt to whatever system you copy them to, and will save you from having to fix all of them if you change hostname (and ISP).
Of course, these days your machine's hostname might not match anything that your ISP has set for you. So you might want to extract your IP address and use that instead of your idea of your hostname. I'll leave the extraction of your IP address from the output of the 'ifconfig' command using sh, awk, PERL, TCL or whatever, as an exercise to the reader, it's not difficult (*).
- (Here's an example using just shell builtins for the parsing: '/sbin/ifconfig eth0 | { read x; IFS=": " read x x a x; echo $a; }' )
Another problem with using straight IP addresses is that you might be going through some sort of IP masquerading (NAT --- network address translation) between your local system and the remote.
There is a better way!
USE ssh!
ssh will automatically handle your DISPLAY variable for you. When you establish a remote shell session using ssh it creates it's own version of the DISPLAY variable, one which points "localhost:10" (or localhost:11, etc).
What? Yep! You read that right. Your ssh client tells the remote sshd (daemon/server) to pretend to be the "10th (or later) X server" on the remote system. The the sshd will listen for X protocol activity on TCP port 6010 (or 6011, 6012, etc) and relay that through to your local X server. This feature of ssh is called X11 port forwarding. It is completely transparent and automatic.
On top of that all the traffic between your remote X clients and your local display server is encrypted from the time it gets to the remote sshd (X proxy) until it gets to your local ssh client process. It can't be sniffed or spoofed (not without some heretofore unheard of cryptanalysis or the application of a WHOLE LOT or brute computing force).
Also, when you install and configure ssh you can put one or more public keys in the ~/.ssh/authorized_keys on each of the remote systems to which you want access. So long as you keep the corresponding private keys secure on your system, you can safely access your remote accounts without a password. It's as convenient as 'rsh' and as safe as Kerberos (possibly more so).
You can even publish one or more ssh public identities. Then anyone who wants to let you access an account on any of their systems can just add that to the authorized_keys file there. Possession of the public key can let them let you in, while not directly compromising the security of any other sites to which you have access.
On top of all that you can also use the 'scp' program as a "secure 'rcp'." That's a way to copy files to and from a remote system using basically the same syntax as a 'cp' command and without having to start up a copy of ftp or C-Kermit, etc.
It's also possible to set up ssh tunnels and run any number of common protocols through them.
There's also an ssh-agent program. This is a way of allowing you to login, start up one shell under the ssh-agent, give it your passphrase (in effect unlocking your local private key) and having all your other ssh commands in all of descendent processes, including those on remote systems all automatically use the "unlocked" key. When you exit that one ssh-agent shell or X session, you've effectively "locked" the key back up. (It's actually a rather clever hack).
Oh, yeah! That X11 forwarding trick works right through any IP masquerading, NAT, or applications proxying. It's just more traffic between your ssh client and the remote daemon multiplexed in band with the rest of your session.
It makes no sense to use rsh or telnet in the modern world. We should all switch to more secure protocols like ssh, Kerberos etc. (Ironically, the emergence of IPSec and the future of ubiquitously secure DNS may eventually make the 'net safe for plain telnet and rsh protocols. But that's a different story.)
|
|
|
thanks for the responses:
I have no problem starting X programs and seeing them display on the remote
machine, and X11 Forwarding is on in the sshd_config. what i am trying to do
is export the entire desktop from the server to the remote machine.
someone told me that this was possible using this series of commands:
#X :1 &
xterm -display :1
ssh (server ip)
run xsession
this doesn't work, and the version i've tried is:
#X :1 &&
xterm -display :1
ssh (server ip)
run xsession
this results in a complaint: xterm Xt error: Can't open display:
I hope all this clears up any confusion about my question, and brings us
closer to an answer.
thanks again,
adam
-----Original Message-----
From: [email protected]
[mailto:[email protected]]On Behalf Of Jesse Goerz
Sent: Tuesday, August 21, 2001 8:00 AM
To: [email protected]
Subject: Re: ssh exporting display
On Tuesday 21 August 2001 02:57, Adam Ingram-Goble wrote:
> Hi all!
> I'm having trouble and after exhausting everything else i could think of
> i'm asking it here. I want to use ssh to login to my homeserver, and
> export an xsession to my laptop. when i execute startx, it doesn't throw
> any errors, and i can see in top that the gnome login got started just
> fine, but all i see on the laptop is the xfree setup messages scrolling
> by. i have no idea how to approach this problem because i've tried #
> export
> DISPLAY=(laptop):1 in addition to just trying # startx, but i get no
> *love*.....
>
> any help/direction on resolving this is appreciated. note that i am
trying
> this from the console (outside of X on my laptop....gdm is disabled so i
> boot to text).
>
> thanks
> adam
Is X Forwarding allowed on your server? I believe it's off by default. Check
/etc/ssh/sshd_config on your server.
|
|
|
> The second user needs to know both the display ($DISPLAY), and have
> xauth access to it. Again assuming :0 is your active session:
>
> o User 2 runs: export DISPLAY=:0
> o User 1 queries xauth: "xauth list | grep :0"
> o User 2 adds this display to their xauth list. I'd suggest cut and
> paste through the X Windows clipboard:
>
> xauth add <xauth cookie for display :1>"For more information: man xauth.
I personally prefer sudo (apt-get install sudo), put yourself into /etc/sudoers as:
your-user-name ALL=(ALL) ALL
That way you can launch _any_ program as root from an user X-session.
You could be more restrictive with your permissions if you don't need
more than a few commands as root.
|
|
|
In a University of Maryland class, circa 1979, I first heard about windows (with respect to computers, of course). At that time, most computers, when you logged into them, looked like ASCII terminals - no Windows (notice the capitalization). The idea of having multiple active sessions on a single screen was fascinating. When I first encountered the X Windowing System, many years later, I realized the concept had taken a great leap forward. The windows could be running on many different systems and sending their displays to my local screen.
These days, my company mandated PC runs, not only Windows NT but also X Windowing System software (Exceed - http://www.hummingbird.com/products/nc/exceed/index.html). Currently, my PC monitor stands in for my SPARCstation 20 (with its still dead frame buffer). As much as I've watched the evolution from low res screen fonts to crisp images and international alphabets, I am still somewhat amazed, and a bit disoriented, by the conjunction of multiple systems sharing a single screen and a single keyboard.
The particular setup I employ involves a series of telnet sessions and Xterms vying for my attention, plus a couple of desktop tools residing on the NT box. I quickly found I had to use color and window banners to remind me which window was connected to which system. My favorite Exceed command is now:
DISPLAY=10.1.2.3:0.0;export DISPLAY;/usr/openwin/bin/xterm -ls -sl 2000 -sb -bg darkblue -fg white -fn 9x15 -title boson &
This command gives me a pleasant blue xterm with a label and a readable font.
Exceed seems to take care of the xhost+ command I would normally run on one Unix system to allow another to use its display. The command above, which is run on the SS20 (i.e., the Unix system with a non- working monitor), sets its display to the PC and starts an xterm window with the proper display characteristics.
Of course, xterms are just the beginning of what you can do with your X server. You can run all of the typical desktop tools -- like File Manager, Image Tool, and the like. Once you have enough tools running on your PC, it becomes even more difficult to remember that the system serving up the windows is not running Unix. I may even have trouble deciding what to run on my Sun monitor and what to run on my PC monitor when the refurbished frame buffer arrives to breathe life back into my Sun monitor. Going back to two keyboards and two screens might seem like more of an annoyance than a benefit.
Google matched content |