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)
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 application. Read ya, Phil
Created attachment 10946 [details] openssh -v output comments between lines of +++++ and -----
Created attachment 10947 [details] output from ssh -v on RH 6.1 comments between ++++ and ----
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).
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 package. Read ya, Phil
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
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.
The last comment was supposed to go into bug 61524, so ignore. Read ya, Phil