When one fires up kppp on say, 192.168.1.1 from 192.168.1.3, using .3's
display, using openssh to manage X11 forwarding (although I imagine this
will be a common problem), the userhelper GTK password dialog pops up, asks
for the root password and then quits, leaving kppp unstarted.
Is this a problem with userhelper, X11 forwarding or kppp?
My second box will be returning to its owner soon, so I won't be able to
duplicate this bug much longer.
Which version of openssh are you running? Are there any error messages being
printed to the console by kppp?
I'm running openssh-1.2.1pre25-1 (with openssl-0.9.4-3), both built from SRPMS
found on http://www.firedrake.org/openssh/files/
There weren't any error messages, kppp just died silently.
Ditto with rp3-config. And this is with a connect to myself (ie.
I hope I'm not barking up the wrong tree here, but most other apps I tried,
including GIMP and netscape worked fine.
This is the first I've heard of this, but it sounds like it might be an obscure
usermode bug of some kind, so I can't be completely sure. Are there any
error messages in /var/log/messages or /var/log/secure? Is there any indication
of usermode crashing somehow (core dump, error messages, etc)? When you ssh in
as root, does running /usr/sbin/kppp directly work?
When ssh'ing from a normal user under X to the root user, and executing kppp (as
root), I get the following error:
-- error start --
X11 connection rejected because of wrong authentication.
kppp: Fatal IO error: client killed
-- error end --
I assume running as root bypasses userhelper?
Ditto for ssh'ing from root to root. Also, for some strange reason, when I log
out, the ssh session refuses to die on the client side. Nothing of interest in
any of the logfiles.
Programs gated by userhelper have a symlink in /usr/bin/<appname> that points
to userhelper, and userhelper's configuration file under
/etc/security/console.apps lists the "real" binary's location, which is almost
always in /usr/sbin. Running this program from /usr/sbin bypasses userhelper
entirely if you're root, and should not work (or at least, not completely) as a
Ah, this was a *very* specific usermode/pam_xauth interaction problem, which
should be solved by today's errata.