Bug 28351 - apacheconf fails to run over ssh forwarded connection
apacheconf fails to run over ssh forwarded connection
Product: Red Hat Linux
Classification: Retired
Component: apacheconf (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Phil Knirsch
David Lawrence
Depends On:
  Show dependency treegraph
Reported: 2001-02-19 17:27 EST by Stephen Samuel
Modified: 2015-03-04 20:08 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-02-26 09:28:15 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
openssh -v output comments between lines of +++++ and ----- (8.83 KB, text/plain)
2001-02-24 12:22 EST, Stephen Samuel
no flags Details
output from ssh -v on RH 6.1 comments between ++++ and ---- (3.96 KB, text/plain)
2001-02-24 12:27 EST, Stephen Samuel
no flags Details

  None (edit)
Description Stephen Samuel 2001-02-19 17:27:29 EST
From Bugzilla Helper:
User-Agent: Mozilla/4.76 [en] (X11; U; Linux 2.2.16-3 i686)

Reproducible: Always
Steps to Reproduce:
1.ssh [-v] to fischer machine
2.start apacheconf
3.Enter root password in window (if not logged in as root).

Actual Results:  claims authetication problems.

Expected Results:  apacheconf should start up.

Works fine if starting on local machine, or using unencrypted channel
  myscreen:  xhost + fischer.me.com
  fischer:   export DISPLAY=myscreen.me.com:0
  fischer:   apacheconf
Unfortunately, this loses most (all) of the the advantage of using
ssh (insofar as security of the X connection)
happens using ssh1 protocol. Have not tried under ssh2 auth.
May be alchemist related... Had reports of similar problems with
other alchemest related components (haven't tested yet)
Comment 1 Phil Knirsch 2001-02-20 05:37:03 EST
I have just checked it with our latest public beta (released 2/19/01), and with
that one it works fine.

Remember you have to have X11 forwarding enabled as well as this is a GUI

Read ya, Phil
Comment 2 Stephen Samuel 2001-02-24 12:22:39 EST
Created attachment 10946 [details]
openssh -v output comments between lines of +++++ and -----
Comment 3 Stephen Samuel 2001-02-24 12:27:52 EST
Created attachment 10947 [details]
output from ssh -v on RH 6.1 comments between ++++ and ----
Comment 4 Stephen Samuel 2001-02-24 12:51:24 EST
Error still occurs on wolverine.

The X server machines are RH6.1 and RH7.0 
I don't have a second rawhide machine.
Other than apacheconf, X seems to work fine... In fact, 
if you don't start apacheconf as root, it opens an X password
requestor window -- then STILL fails to open the main window.
  In the test cases attached, I start an X window from the rawhide 
machine to separate the (somewhat verbose) ssh debug output from the 
apacheconf error (1 line).
Comment 5 Phil Knirsch 2001-02-26 09:28:05 EST
OK, i finally got managed to reproduce the bug, although only as root, but
nonetheless, i think that might be related to the SSH you are using.

After figuring out what is happening i came to the conclusion that this is a
general problem of consolehelper/userhelper and tried it with other
consolehelper programs which all showed the same problems. I can now even
reproduce it connecting from a wolverine machine to another wolverine one, so
it's not a SSH bug either.

I think the problem lies in the fact that consolehelper/userhelper set and get
the XAUTHORITY environment variable wrongly in the case when in run it as root,
in your case for the normal user as well (normal user works for me...).

You can simulate the effect if you ssh to your 7.1 machine and type

unset XAUTHORITY and try to run any X11 program: You'll get the same message
from ssh as with the bindconf wrapped through consolehelper.

I haven't found the exact place where things go wrong in the code yet, but as
soon as i have found it i'll fix it. It's now rather a bug in the usermode

Read ya, Phil
Comment 6 Phil Knirsch 2001-02-27 08:58:53 EST
OK, the problem was actually a usermode/userhelper/consolehelper problem resp.
even a pam related problem:

Pam obviously resets some parts of the environment of the current process if you
start a new session. Unfortunately the XAUTHORITY was set before a new pam
session was created and got removed during the new session.

Fixed it now in usermode package, which incidently fixes the other X11 and
openssh consolehelper app problems as well. ;)

Read ya, Phil
Comment 7 Stephen Samuel 2002-03-20 18:02:26 EST
A workaround can be built with xauth:

( eval export HOME=~$USER ; xauth nlist ) | xauth nmerge - ; apacheconf 

(ugh!) This forces the xauth information into where apacheconf appears to insist
on looking for it.
Comment 8 Phil Knirsch 2002-03-21 04:09:04 EST
The last comment was supposed to go into bug 61524, so ignore.

Read ya, Phil

Note You need to log in before you can comment on or make changes to this bug.