SecureCRT/Exceed/X11 Forwarding
Aaron J Mackey
I've checked off the "X11 forwarding" box in advanced settings, and
started the Exceed server ... I open a SecureCRT session to
my.favorite.host.com, and echo $DISPLAY shows my.favorite.host.com:0
What have I forgotten to do?
Thanks,
-Aaron
Etienne Detroit
Do you have startup script that sets $DISPLAY? I have never used any
ssh client for windows so things may be different but on UNIX,
$DISPLAY will be something like my.favorite.host.com:10:0. This is
set by the server so if you are connecting to a UNIX/Linux/BSD this is
what I would expect even for a windows client.
Does the server accept X11 forwarding? Every sshd I have used lets
you turn it off or on and I beleive it is off by default.
Alan J. Flavell
> Aaron J Mackey wrote:
> >
> > I've checked off the "X11 forwarding" box in advanced settings, and
> > started the Exceed server ... I open a SecureCRT session to
> > my.favorite.host.com, and echo $DISPLAY shows my.favorite.host.com:0
That scenario works for me, except I'm kicking it off from ttssh
rather than secureCRT.
> > What have I forgotten to do?
>
> Do you have startup script that sets $DISPLAY?
It looks like it, and if so, then the solution is to take it out.
> I have never used any
> ssh client for windows so things may be different
Not in relation to the issue being discussed here.
> $DISPLAY will be something like my.favorite.host.com:10:0.
Indeed, "for some value of 10".
> This is
> set by the server so if you are connecting to a UNIX/Linux/BSD this is
> what I would expect even for a windows client.
Confirmed.
> Every sshd I have used lets
> you turn it off or on and I beleive it is off by default.
Erm, my colleague was doing a fresh install of openssh on linux just
the other day; I'm sure we found that the default ssh _client_ setting
did not request X forwarding, but the default sshd _server_ setting
_did_ permit it.
As a first priority I'd say find out what's setting that $DISPLAY
variable at the remote system, and stop it. ssh's X forwarding can't
work until you do. If there's still an problem, then take it from
there.
Use some trivial X application as your diagnostic, e.g xlogo (I keep
seeing our users trying to start up some massive application like X
Netscape, or Ghostview, as their diagnostic when they're having this
type of problem - big waste of time).
Oh, and if you work this way then you can set your eXceed's security
to use a hosts list, and set the only permitted host to localhost =
127.0.0.1.
hope that helps
Aaron J Mackey
On Sun, 27 Aug 2000, Alan J. Flavell wrote:
> On Sun, 27 Aug 2000, Etienne Detroit wrote:
>
> > Aaron J Mackey wrote:
>
> > > What have I forgotten to do?
> >
> > Do you have startup script that sets $DISPLAY?
>
> It looks like it, and if so, then the solution is to take it out.
Well, you're both wrong. If I uncheck the "X11 Forwarding" checkbox in
SecureCRT and open a session, "echo $DISPLAY" returns "DISPLAY: Undefined
variable." If I recheck the box and open a new session, I get back the
remote host (i.e. not my local host at all). Additionally none of my
.cshrc, .login, .profile, /etc/profile.d/* or other files have any mention
of setting DISPLAY for me. It seems like SecureCRT doesn't know what to
tell the remote host for DISPLAY, and so the remote host is filling in
with its own hostname. Do I also need to forward a literal port number?
> Oh, and if you work this way then you can set your eXceed's security
> to use a hosts list, and set the only permitted host to localhost =
> 127.0.0.1.
No, I want the remote host to be able to open an xterm (or other xwindow
app) on my local host running Exceed.
-Aaron
--
o ~ ~ ~ ~ ~ ~ o
/ Aaron J Mackey \
\ Dr. Pearson Laboratory /
\ University of Virginia \
/ (804) 924-2821 \
\ ama...@virginia.edu /
o ~ ~ ~ ~ ~ ~ o
Richard E. Silverman
Aaron> If I recheck the box and open a new session, I get back the
Aaron> remote host (i.e. not my local host at all)... It seems like
Aaron> SecureCRT doesn't know what to tell the remote host for
Aaron> DISPLAY, and so the remote host is filling in with its own
Aaron> hostname...
>> Oh, and if you work this way then you can set your eXceed's
>> security to use a hosts list, and set the only permitted host to
>> localhost = 127.0.0.1.
Aaron> No, I want the remote host to be able to open an xterm (or
Aaron> other xwindow app) on my local host running Exceed.
I think you're confused about how X forwarding works. Etienne is right,
and the fact the host part of DISPLAY is the remote host is normal and
correct. What happens is this: the remote sshd acts as an X proxy,
setting DISPLAY for the login session to point to the proxy. When it
receives connections to the proxy display, it opens a channel inside the
SSH session back to the SSH client, which in turn makes its own X
connection to the (real) local display, forming a tunnel for the X
connection. Since from the X server's point of view the forwarded
connections come from the same (client) host, you can restrict the X
server to taking connections only from localhost.
The only odd thing here is the display number. Normally, it would be
"remote:10.0" or something like that, so as to skip over any real X
displays the remote host may have. You haven't said what version of SSH
is on the server; if it's SSH1 or OpenSSH, take a look at its
X11DisplayOffset setting. Also, I assume you've tried running an X
client. What exactly happens when you do?
--
Richard Silverman
sl...@shore.net
Chip Christian
Any clues why I can't seem to get X11 forwarding to work through a NAT firewall?
I'm using openssh pn both ends, Linux client, Solaris server. Works just fine
when the server is inside the firewall.
--
print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<>
)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`