343 lines
14 KiB
HTML
343 lines
14 KiB
HTML
<!--startcut ======================================================= -->
|
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
|
|
<html>
|
|
<head>
|
|
<META NAME="generator" CONTENT="lgazmail v1.3C.j">
|
|
<TITLE>The Answer Guy 52: Exporting a DISPLAY</TITLE>
|
|
</HEAD><BODY BGCOLOR="#FFFFFF" TEXT="#000000"
|
|
LINK="#3366FF" VLINK="#A000A0">
|
|
<!-- ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: -->
|
|
<H4>"The Linux Gazette...<I>making Linux just a little more fun!</I>"</H4>
|
|
<P> <hr> <P>
|
|
<!-- ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: -->
|
|
<center>
|
|
<H1><A NAME="answer">
|
|
<img src="../../gx/dennis/qbubble.gif" alt="(?)"
|
|
border="0" align="middle">
|
|
<font color="#B03060">The Answer Guy</font>
|
|
<img src="../../gx/dennis/bbubble.gif" alt="(!)"
|
|
border="0" align="middle">
|
|
</A></H1>
|
|
<BR>
|
|
<H4>By James T. Dennis,
|
|
<a href="mailto:linux-questions-only@ssc.com">linux-questions-only@ssc.com</a><BR>
|
|
LinuxCare,
|
|
<A HREF="http://www.linuxcare.com/">http://www.linuxcare.com/</A>
|
|
</H4>
|
|
</center>
|
|
|
|
<p><hr><p>
|
|
<!-- endcut ======================================================= -->
|
|
<!-- begin 19 -->
|
|
<H3 align="left"><img src="../../gx/dennis/qbubble.gif"
|
|
height="50" width="60" alt="(?) " border="0"
|
|
>Exporting a DISPLAY</H3>
|
|
|
|
|
|
<p><strong>From John Hinsley on Wed, 29 Mar 2000
|
|
</strong></p>
|
|
<!-- ::
|
|
Exporting a DISPLAY
|
|
~~~~~~~~~~~~~~~~~~~
|
|
:: -->
|
|
<P><STRONG>
|
|
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?
|
|
</STRONG></P>
|
|
<P><STRONG>
|
|
John Hinsley
|
|
</STRONG></P>
|
|
<BLOCKQUOTE><IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
|
|
HEIGHT="28" WIDTH="50" BORDER="0"
|
|
>
|
|
Short answer: Use ssh instead.
|
|
</BLOCKQUOTE>
|
|
<BLOCKQUOTE>
|
|
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).
|
|
</BLOCKQUOTE>
|
|
<BLOCKQUOTE>
|
|
So, if you issue a '<tt>set</tt>', '<tt>env</tt>' or '<tt>printenv</tt>' command and look
|
|
you might find that your DISPLAY variable IS set. However, it's
|
|
probably set to the wrong thing.
|
|
</BLOCKQUOTE>
|
|
<BLOCKQUOTE>
|
|
When you run '<tt>startx</tt>' on the local system, it sets your DISPLAY
|
|
variable to something like: <tt>DISPLAY=:0.0</tt> 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 "<tt>s</tt>" in a "long"
|
|
'<tt>ls</tt>' output). That works for the local processes talking to the
|
|
local X server.
|
|
</BLOCKQUOTE>
|
|
<BLOCKQUOTE>
|
|
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
|
|
<tt>DISPLAY=123.45.67.85:0.0</tt> or <tt>DISPLAY=foo.bar.not:0.0</tt>
|
|
</BLOCKQUOTE>
|
|
<BLOCKQUOTE>
|
|
Programs that are linked against X libraries will automatically
|
|
search their environment for a <tt>DISPLAY</tt> 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).
|
|
</BLOCKQUOTE>
|
|
<BLOCKQUOTE>
|
|
So, one solution is to use the following sort of command
|
|
(assuming that you are using a Bourne compatible shell like
|
|
'<tt>bash</tt>' which is the Linux default):
|
|
</BLOCKQUOTE>
|
|
<BLOCKQUOTE><BLOCKQuote><code>
|
|
DISPLAY=your.local.hostname:0.0 telnet to.your.remote...
|
|
</code></BLOCKQuote></BLOCKQUOTE>
|
|
<BLOCKQUOTE>
|
|
... this variation of the familiar syntax sets this value
|
|
for the <tt>DISPLAY</tt> 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).
|
|
</BLOCKQUOTE>
|
|
<BLOCKQUOTE>
|
|
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:
|
|
</BLOCKQUOTE>
|
|
<BLOCKQUOTE><BLOCKQuote><code>
|
|
DISPLAY=`hostname`:0.0 telnet ...
|
|
</code></BLOCKQuote></BLOCKQUOTE>
|
|
<BLOCKQUOTE>
|
|
... 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).
|
|
</BLOCKQUOTE>
|
|
<BLOCKQUOTE>
|
|
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 '<tt>ifconfig</tt>' command using <tt>sh</tt>, <tt>awk</tt>, PERL, TCL or
|
|
whatever, as an exercise to the reader, it's not difficult (*).
|
|
</BLOCKQUOTE>
|
|
<BLOCKQUOTE><ul>
|
|
<li> (Here's an example using just shell builtins
|
|
for the parsing:
|
|
'<TT>/sbin/ifconfig eth0 |
|
|
{ read x; IFS=": " read x x a x; echo $a; }</tt>' )
|
|
</ul></BLOCKQUOTE>
|
|
<BLOCKQUOTE>
|
|
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.
|
|
</BLOCKQUOTE>
|
|
<BLOCKQUOTE>
|
|
There is a better way!
|
|
</BLOCKQUOTE>
|
|
<BLOCKQUOTE>
|
|
USE ssh!
|
|
</BLOCKQUOTE>
|
|
<BLOCKQUOTE>
|
|
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).
|
|
</BLOCKQUOTE>
|
|
<BLOCKQUOTE>
|
|
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.
|
|
</BLOCKQUOTE>
|
|
<BLOCKQUOTE>
|
|
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).
|
|
</BLOCKQUOTE>
|
|
<BLOCKQUOTE>
|
|
Also, when you install and configure ssh you can put one or
|
|
more public keys in the <tt>~/.ssh/authorized_keys</tt> 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 '<tt>rsh</tt>' and as safe as Kerberos (possibly more so).
|
|
</BLOCKQUOTE>
|
|
<BLOCKQUOTE>
|
|
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.
|
|
</BLOCKQUOTE>
|
|
<BLOCKQUOTE>
|
|
On top of all that you can also use the '<tt>scp</tt>' 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 '<tt>cp</tt>' command
|
|
and without having to start up a copy of <tt>ftp</tt> or C-Kermit, etc.
|
|
</BLOCKQUOTE>
|
|
<BLOCKQUOTE>
|
|
It's also possible to set up ssh tunnels and run any number of
|
|
common protocols through them.
|
|
</BLOCKQUOTE>
|
|
<BLOCKQUOTE>
|
|
There's also an <tt>ssh-agent</tt> 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).
|
|
</BLOCKQUOTE>
|
|
<BLOCKQUOTE>
|
|
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.
|
|
</BLOCKQUOTE>
|
|
<BLOCKQUOTE>
|
|
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.)
|
|
</BLOCKQUOTE>
|
|
<BLOCKQUOTE>
|
|
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.
|
|
</BLOCKQUOTE>
|
|
<em><p>[ There have also been some issues raised of compatibility with
|
|
1.2.x, and a smooth upgrade path is rather important to most
|
|
sysadmins.
|
|
</p><p>-- Heather ]</p></em>
|
|
|
|
<BLOCKQUOTE>
|
|
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.
|
|
</BLOCKQUOTE>
|
|
<BLOCKQUOTE>
|
|
You can find more about ssh at:
|
|
</BLOCKQUOTE>
|
|
<BLOCKQUOTE><DL><DT>
|
|
SSH Communications Inc.
|
|
<DD><A HREF="http://www.ssh.org"
|
|
>http://www.ssh.org</A>
|
|
</DL></BLOCKQUOTE>
|
|
<BLOCKQUOTE>
|
|
... and you can learn about OpenSSH (the "more free-er" version
|
|
of ssh 1.2.x) at:
|
|
</BLOCKQUOTE>
|
|
<BLOCKQUOTE><DL><DT>
|
|
OpenSSH
|
|
<DD><A HREF="http://www.openssh.com"
|
|
>http://www.openssh.com</A>
|
|
</DL></BLOCKQUOTE>
|
|
<BLOCKQUOTE>
|
|
(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?).
|
|
</BLOCKQUOTE>
|
|
<BLOCKQUOTE>
|
|
You can also learn more about IPSec (secure IP) by reading
|
|
about the Linux <A HREF="http://www.xs4all.nl/~freeswan/">FreeS/WAN</A> project:
|
|
</BLOCKQUOTE>
|
|
<BLOCKQUOTE><DL><DT>
|
|
FreeS/WAN
|
|
<DD><A HREF="http://www.freeswan.org/"
|
|
>http://www.freeswan.org</A>
|
|
</DL></BLOCKQUOTE>
|
|
|
|
<!-- sig -->
|
|
|
|
|
|
<!-- end 19 -->
|
|
<!--startcut ======================================================= -->
|
|
<P> <hr> <P>
|
|
<H5 align="center"><a href="http://www.linuxgazette.com/copying.html"
|
|
>Copyright ©</a> 2000, James T. Dennis
|
|
<BR>Published in <I>The Linux Gazette</I> Issue 52 April 2000</H5>
|
|
<H6 ALIGN="center">HTML transformation by
|
|
<A HREF="mailto:star@tuxtops.com">Heather Stern</a> of
|
|
Tuxtops, Inc.,
|
|
<A HREF="http://www.tuxtops.com/">http://www.tuxtops.com/</A>
|
|
</H6>
|
|
<P> <hr> <P>
|
|
<!-- begin tagnav ::::::::::::::::::::::::::::::::::::::::::::::::::-->
|
|
<TABLE WIDTH="95%"><TR VALIGN="center" ALIGN="center">
|
|
<TD colspan="2" rowspan="2"><A
|
|
HREF="../lg_answer52.html"
|
|
><IMG SRC="../../gx/dennis/answernew.gif"
|
|
ALT="[ Answer Guy Current Index ]"></A>
|
|
<TD colspan="2" rowspan="2"><A
|
|
HREF="../../tag/kb.html"
|
|
><IMG SRC="../../gx/dennis/answertoc.gif"
|
|
ALT="[ Index of Past Answers ]"></A></td>
|
|
<TD WIDTH="11%"><A HREF="../lg_answer52.html#greeting"><img
|
|
src="../../gx/dennis/smily.gif" alt="greetings" border="0"></A></TD>
|
|
<TD WIDTH="11%"><A HREF="1.html">1</A></TD>
|
|
<TD WIDTH="11%"><A HREF="2.html">2</A></TD>
|
|
<TD WIDTH="11%"><A HREF="3.html">3</A></TD>
|
|
<TD WIDTH="11%"><A HREF="4.html">4</A></TD>
|
|
</TR><TR VALIGN="center" ALIGN="center">
|
|
<TD WIDTH="11%"><A HREF="5.html">5</A></TD>
|
|
<TD WIDTH="11%"><A HREF="6.html">6</A></TD>
|
|
<TD WIDTH="11%"><A HREF="7.html">7</A></TD>
|
|
<TD WIDTH="11%"><A HREF="8.html">8</A></TD>
|
|
<TD WIDTH="11%"><A HREF="9.html">9</A></TD>
|
|
</TR><TR VALIGN="center" ALIGN="center">
|
|
<TD WIDTH="10%"><A HREF="10.html">10</A></TD>
|
|
<TD WIDTH="10%"><A HREF="11.html">11</A></TD>
|
|
<TD WIDTH="10%"><A HREF="12.html">12</A></TD>
|
|
<TD WIDTH="10%"><A HREF="13.html">13</A></TD>
|
|
<TD WIDTH="11%"><A HREF="14.html">14</A></TD>
|
|
<TD WIDTH="11%"><A HREF="15.html">15</A></TD>
|
|
<TD WIDTH="11%"><A HREF="16.html">16</A></TD>
|
|
<TD WIDTH="11%"><A HREF="17.html">17</A></TD>
|
|
</TR><TR VALIGN="center" ALIGN="center">
|
|
<TD WIDTH="10%"><A HREF="18.html">18</A></TD>
|
|
<TD WIDTH="10%"><A HREF="19.html">19</A></TD>
|
|
<TD WIDTH="10%"><A HREF="20.html">20</A></TD>
|
|
<TD WIDTH="10%"><A HREF="21.html">21</A></TD>
|
|
<TD WIDTH="11%"><A HREF="22.html">22</A></TD>
|
|
<TD WIDTH="11%"><A HREF="23.html">23</A></TD>
|
|
<TD WIDTH="11%"><A HREF="24.html">24</A></TD>
|
|
</TR></TABLE>
|
|
<!-- end tagnav ::::::::::::::::::::::::::::::::::::::::::::::::::::-->
|
|
<P> <hr> <P>
|
|
<!-- begin lgnav ::::::::::::::::::::::::::::::::::::::::::::::::::: -->
|
|
<A HREF="../index.html"
|
|
><IMG SRC="../../gx/indexnew.gif" ALT="[ Table Of Contents ]"></A>
|
|
<A HREF="../../index.html"
|
|
><IMG SRC="../../gx/homenew.gif" ALT="[ Front Page ]"></A>
|
|
<A HREF="../lg_bytes52.html"
|
|
><IMG SRC="../../gx/back2.gif" ALT="[ Previous Section ]"></A>
|
|
<A HREF="../../faq/index.html"
|
|
><IMG SRC="../../gx/dennis/faq.gif"
|
|
ALT="[ Linux Gazette FAQ ]"></A>
|
|
<A HREF="../lg_tips52.html"
|
|
><IMG SRC="../../gx/fwd.gif" ALT="[ Next Section ]"></A>
|
|
<!-- end lgnav ::::::::::::::::::::::::::::::::::::::::::::::::::::: -->
|
|
<!-- ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: -->
|
|
</BODY></HTML>
|
|
<!--endcut ========================================================= -->
|