No subject

this particular operation: your local box, your remote box, and your
users's box.  You log into your local box and initiate an X session.
Then you ssh from there to the remote box, setting up the X tunnel
from your remote box (where X clients will run) back to your local box
(which is running the X server).

Now, your user logs in to your remote box from the user's box.  If X
forwarding is enabled for all sshd users, then they can construct a
forwarded X session running X clients on your remote box -- but that
tunnel only goes back to *their* X server.  They can't get to your X
server, so there's not a security concern.

So, I don't see any reason to restrict X forwarding on a security
basis.  Bandwidth or other resources, on the other hand, might be a
legitimate reason to implement this restriction.

To allow yourself in with X forwarding, but not anyone else, I'd run
two sshd processes (with different config files) on two different
ports.  The standard port can have X forwarding turned off; on a
non-standard port, change that sshd's config file to allow forwarding,
then use firewalling (ipfw / ipchains / iptables) to allow connections
only from your trusted machines.

A bit messy, but should work.  Make sure that you understand why
you're going through the extra trouble, however.

t.