Tue Jun 4 12:17:20 MDT 2013
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.
More information about the LUG