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. ssh 192.168.1.1). 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 non-root user.
Ah, this was a *very* specific usermode/pam_xauth interaction problem, which should be solved by today's errata.