[TriLUG] Another forwarding X11 question
Jeremy P
jeremyp at pobox.com
Tue Apr 23 12:27:03 EDT 2002
On Tue, 23 Apr 2002, Andrew Perrin wrote:
> Jeff,
>
> In general you need to make sure each hop - including authentication hops
> - has a path back to the actual display.
>
> > Host (B) tries to connect via ssh -X host.A
>
> When you say "tries," I assume you mean also "succeeds," right? Does ssh
> -v -X tell you anything interesting?
>
> > Host (B) tries to run an application that requires X -- ethereal, tried
> > running as both root, and normal user and Host (B) gets this error:
>
> To get to root on A, do you use su or ssh? If su, you're breaking the
> chain - there's no channel for the X packets to get through.
If you use Red Hat Linux, by default "su" contains the correct PAM magic
to forward the "authentication token" from the logged-in user to root.
See the man page for "pam_xauth" for details. You can use files in a
~/.xauth directory to control its behavior, although the default setup
works for me.
Do not use "su -" to try to start a "login" shell. That will destroy the
X authentication tokens set up by ssh and will break this whole process.
Here's the setup that always works fine for me:
Host jeremy is my local computer, running the ssh client (I've used
several versions, currently openssh-3.1p1). Host mega is the server box
from which we want to run an X application as root. It's running sshd
(from openssh-3.1p1-2). On "jeremy", /etc/ssh/ssh_config has "ForwardX11
yes", so all I need to do is this:
jeremy $ ssh mega
mega $ su
Password:
mega # application &
The application reads the xauth keys manipulated by su and pam_xauth,
which allows root to connect to the local host (mega) as "jeremy". It is
connecting to mega:10.0, which is the X tunnel setup by sshd. The tunnel
sends the X connection back to the display at "jeremy".
I probably don't have all of the terminology exactly correct, but that's
the general process. It works well, and means you can deny root logins
but still run X applications as root on a remote server.
--Jeremy
More information about the TriLUG
mailing list