"The Linux Gazette...making Linux just a little more fun!"

Exporting a DISPLAY

From John Hinsley on Wed, 29 Mar 2000

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 correspoding 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.)

ssh has always been free for personal use. It's always included the source code. Version 1.2.x was under a very liberal license. ssh 2.x has been somewhat less popular, since it was somewhat more commercialized and many sysadmins have shied away from it, unsure of whether they can use it freely, etc.

There is some politics in that; and ssh 1.2.x was (and STILL IS) more than adequate for most needs. Consequently it is used much more widely than the newer versions.

You can find more about ssh at:

SSH Communications Inc.

https://www.ssh.org

... and you can learn about OpenSSH (the "more free-er" version of ssh 1.2.x) at:

OpenSSH

https://www.openssh.com

(Does anyone else notice the irony of the more commercial package using a .org domain name while the "more free-er" package has a .com?).

You can also learn more about IPSec (secure IP) by reading about the Linux FreeS/WAN project:

FreeS/WAN

https://www.freeswan.org

Copyright © 2000, James T. Dennis
Published in The Linux Gazette Issue 52 April 2000

HTML transformation by Heather Stern of Tuxtops, Inc., https://www.tuxtops.com/

					1	2	3	4
				5	6	7	8	9
10	11	12	13	14	15	16	17
18	19	20	21	22	23	24