SSH not setting DISPLAY variable
Adam Nielsen
I'm having a rather strange problem with OpenSSH (3.1p1) forwarding X11
connections. Because I want to forward the X11 connection through multiple
computers, I originally though that was the problem, however I've narrowed
it down to the final computer in the chain.
I have two computers running Slackware 8.0, both using the same version of
SSH and one of them works perfectly, but the other one does not. And as
both computers are set up almost identically I don't know what could be
wrong. This is what happens on the computer that works:
bash$ ssh localhost -X
password:
bash$ echo $DISPLAY
localhost:10.0
bash$ logout
On the second computer, "echo $DISPLAY" just gives a blank line, so
obviously no X programs will run. It also only affects incoming
connections - if I connect out from the not-working computer to somewhere
else then the connection is forwarded back to my display ok, but I can't
get my computer forwarded back to someone else's display.
If I run ssh in verbose mode, I get these lines towards the end:
...
debug3: tty_make_modes: 91 1
debug3: tty_make_modes: 92 0
debug3: tty_make_modes: 93 0
debug2: x11_get_proto /usr/X11R6/bin/xauth list :0.0 2>/dev/null
debug1: Requesting X11 forwarding with authentication spoofing.
debug1: channel request 0: x11-req
...
These lines are the same on both computers.
I think the problem lies with "xauth" - if I run "xauth list" on the
working computer, there is a new entry added after I've ssh-ed to it,
however the non-working computer's xauth list remains unchanged. Does
anyone know what's going on??? I hope I haven't confused you too much ;-)
Thanks,
Adam.
Dan Oviatt
On the box where it does not work, is the DISPLAY set in the
environment? In other words, BEFORE you ssh, if you do an env and look
at your environment is DISPLAY set? If not, X forwarding will not
work. You must set the DISPLAY to where you want to X app to run on
the client before you ssh, without this initial DISPLAY setting, ssh
has no idea where to send the output.
Adam Nielsen
> environment?
Yep, it's set (to ":0") But regardless of which computer has DISPLAY set,
once I ssh into my main computer DISPLAY becomes blank/nonexistent. So if
I ssh to myself (i.e. localhost) it doesn't work, and if I ssh to here from
another computer it still doesn't work, even though ssh-ing to anywhere
that's not this computer works fine. The DISPLAY is always set before
running ssh.
All the ssh config files are the same, and I always use the -X parameter to
forward the connection.
So as you can see, I'm really stuck as to the cause of the problem!
Thanks for your reply,
Adam.
those who know me have no need of my name
>> On the box where it does not work, is the DISPLAY set in the
>> environment?
>
>Yep, it's set (to ":0") But regardless of which computer has DISPLAY set,
are you sure it's exported (so that ssh can see it)?
>once I ssh into my main computer DISPLAY becomes blank/nonexistent.
if DISPLAY is exported to ssh then i'd guess that your login scripts
inappropriately unset it.
--
bringing you boring signatures for 17 years
Adam Nielsen
I'm a Linux newbie, so I'm not 100% sure how to check, but if I type
"export" in a console window, DISPLAY is listed with the correct value.
Once I've run "ssh -X localhost" however, DISPLAY is no longer listed if I
type "export"
> if DISPLAY is exported to ssh then i'd guess that your login scripts
> inappropriately unset it.
I've seen that suggestion too, however firstly I'm not entirely sure where
to look, and secondly I haven't modified any login scripts on either
computer and one works but the other doesn't. So I don't think that would
be the problem.
The only thing I can think of is that it's X11 itself, as I just realised
I'm running 4.2.0, and the computer that works is running 4.0.3. I'm
fairly sure it's something to do with the "xauth" program, however even if
I temporarily replace the new version of xauth with the old version, there
is no change. Also note though, that ssh won't forward the connection
regardless of whether the XFree86 server is running on this machine or not
(and I want the X programs forwarded to another machine anyway.)
Is there some reason why xauth would refuse to add anything to
~/.Xauthority on one computer only???
Shweta
those who know me have no need of my name <not-a-rea...@usa.net> wrote in message news:<ukbvuv3...@news.supernews.com>...
Richard E. Silverman
Shweta> How do u export DISPLAY to ssh?
Some shells makr environment variables with a flag noting whether or not
they will be included in the environment of a child process. Thus with
bash, "DISPLAY=foo" would not be enough; you would need "export
DISPLAY=foo". However, if X is working locally (which you should have
checked first, of course), then this is already OK.
--
Richard Silverman
sl...@shore.net
Nico Kadel-Garcia
> > are you sure it's exported (so that ssh can see it)?
>
> I'm a Linux newbie, so I'm not 100% sure how to check, but if I type
> "export" in a console window, DISPLAY is listed with the correct value.
> Once I've run "ssh -X localhost" however, DISPLAY is no longer listed if I
> type "export"
Start examing the setup of your target machine. Does it allow X forwarding
in /etc/ssh/sshd_config? Was it compiled with X windows? (The RPM's
certainly were!) Do you have something in your /etc/profile or /etc/cshrc
messing with your environment and making mistakes?
Clayton Weaver
have a system.xinitrc (whatever its
actually called; this should be close
enough to find it), plus possibly an
.xinitrc in your home directory. Likewise,
the window manager itself (twm, xfce,
windowmaker, afterstep, sawfish, fvwm2, some other gnome or kde thing,
whatever) will have an init file of its own.
Possible locations for system-wide
X11 init files:
/etc/X11/
/etc/X11R6/
/var/lib/X11R6/
/var/X11R6/lib/
/usr/X11R6/lib/X11
etc
Look in any app-defaults subdirectories
you find in these as well as in subdirectories of the top level.
I remember that an xinitrc for twm did
as it's last thing "exec xterm [options]",
and when you logged in you started
up in that particular xterm window. If
you have a comparable setup, then
differences in xterm's defaults could
inhibit the export of $DISPLAY (ie
look for an xtermrc somewhere, system
or ".xtermrc" in your home directories).
The idea that it is an xauth issue has a
certain reasonableness ("Who else besides a security program would care
enough to hide it?"), but not exporting it could be a mere side-effect of some
other change to the default initialization of xterm or a window manager, and a
comment
in the default system init file (or the man page) for one of those may show the
way to fix it.
I noted the other day with XFree86 4.2
that opening xterm windows ran bash
(my login shell), but the .bash_profile and .bashrc files didn't seem to have
been sourced (run). (An environment
variable exported from .bashrc, which is sourced by .bash_profile in my case,
was undefined when I examined it from the
shell prompt in the xterm window.) I
haven't gotten around to finding out why
yet or how to fix it (man xterm, for starters), but ssh could be seeing the
same problem for the same reason.
Regards,
Clayton Weaver
<mailto: cgw...@aol.com>
"Everyone is ignorant, just about different things." Will Rogers
Adam Nielsen
> in /etc/ssh/sshd_config?
Ah...that would be what it was. "X11Forwarding" was set to "no" in
sshd_config, which I hadn't realised even existed. I just assumed
ssh_config was the only config file - what a shame it was such a simple
problem :-( I guess I should use my eyes a little more next time ;-)
Thanks everyone for all your help in solving my problem, I really
appreciate the effort you've gone to with all the long helpful replies!
Adam.
Adam Nielsen
Thanks for your detailed reply!
> If you have a comparable setup, then differences in xterm's defaults could
> inhibit the export of $DISPLAY
I was fairly sure it wouldn't be any X program causing the problem, because
I could actually make up a value for the DISPLAY variable and ssh would
still forward it (on the working computer), even though X wasn't running
and $DISPLAY was fake.
Not that it matters now that it turns out I just made a simple mistake...
> I noted the other day with XFree86 4.2 that opening xterm windows ran
> bash (my login shell), but the .bash_profile and .bashrc files didn't
> seem to have been sourced (run).
I have a similar problem, and the best I could figure out was that in the
bash manpage it says that if bash is invoked with the name "sh" it runs a
different set of login scripts. Perhaps this is what is happening for you?
Thanks again,
Adam.
Richard E. Silverman
>> I noted the other day with XFree86 4.2 that opening xterm windows
>> ran bash (my login shell), but the .bash_profile and .bashrc files
>> didn't seem to have been sourced (run).
AN> I have a similar problem, and the best I could figure out was that
AN> in the bash manpage it says that if bash is invoked with the name
AN> "sh" it runs a different set of login scripts.
Read the INVOCATION section of the bash man page again; this behavior is
exactly what is documented. It does not run .bashrc when started as a
login shell...
--
Richard Silverman
sl...@shore.net
Clayton Weaver
>exactly what is documented. It does not run .bashrc when started as a
>login shell...
It sources ~/.bash_profile as a login
shell. In my .bash_profile I have
. .bashrc
(so I get the variables, aliases,
and shell functions from .bashrc
exported whether bash sources .bash_profile or .bashrc).
The answer was in
/etc/X11/xdm/Xsession
It sources /etc/profile and (if it exists)
"~/.profile" ("Csh considered harmful").
(cd ~ && ln -s .bash_profile .profile)
fixed that.
Thanks for the info.
I'm still wondering why it neither accepts
the public keys generated by ssh-keygen
nor prompts for a password when attempting a ssh->sshd login on localhost,
despite having both of those authentication
methods enabled with openssh-3.4p1, but
that's a problem for another day.
(Log shows "no passphrase", and the keys
were generated with passphrases, but you'd think it would ask for them if that
were the issue, and that doesn't entitle
it to skip the password prompt for a password-authenticated login anyway.
"UseLogin yes" doesn't help.)
Roy Smith
messed up. The symptoms were exactly as described here -- DISPLAY
wasn't being set when she ssh'd to another unix box. MIS insisted that
X port forwarding was turned on in both the client and the server.
To make a long story short, the target box had two different ssh
installs, with different build parameters. There was a complete set of
config files in /etc, and another in /etc/ssh. The sshd that was
currently running was using /etc/ssh/sshd_config, but they had edited
/etc/sshd_config to turn on X11forwarding, and were surprised when it
had no effect.
It pays to check out the dumb stuff before assuming the software is
broken :-)