Re: More SSH Fun (X11 forwarding)

[Dossy <dossy@panoptic.com>]

On 2002.07.01, Vineet Kumar <debian-security@virtual.doorstop.net> wrote:
> So anyway, here's a basic rundown of things to double-check:
> 
> the server has "X11Forwarding yes" in its config (and that config has
> been loaded, i.e. the server has been restarted since the change).

Be specific:  On the server, look at /etc/ssh/sshd_config ...

> the client has X11Forwarding yes in its config, in the right place (i.e.
> after where it says "Host *", and no later declarations override and
> disable it.)

Again, specific:  On the client, look at /etc/ssh/ssh_config ...
and, on the client's ssh_config, it's "ForwardX11" not "X11Forwarding".

Here's a quick way to test:

$ grep -i X11 /etc/ssh/ssh_config /etc/ssh/sshd_config

If you want to filter out any lines that are entirely
commented out:

$ grep -i X11 /etc/ssh/ssh_config /etc/ssh/sshd_config \
    | sed -e 's/#.*//' | egrep -v ':$'

On my system, from this second command, I only get:

/etc/ssh/sshd_config:X11Forwarding yes
/etc/ssh/sshd_config:X11DisplayOffset 10


> you're not connecting with a key which is restricted with a
> no-X11-forwarding directive in the options section of the
> authorized_keys.

Good thing to check, but certainly implies more SSH kung-fu
than the average user.

> DISPLAY is set on the client, and displaying of local X apps works
> before ever attempting a connect to the remote server. This means that
> the local xauth cookie is valid and authorized to connect to the local
> X server.

This is the analog to the standard helpdesk first question of
"is it plugged in?"  Sometimes we forget to ask this one ...

> xauth is found at /usr/bin/X11/xauth, or the correct location is
> specified correctly with an XAuthLocation directive in the remote
> sshd's sshd_config, and the connecting user has correct (+rx)
> permissions on it.

Another good point.

> I'm about to review the thread one more time to see if you've posted any
> "ssh -v" or "sshd -d" outputs that may provide additional insight. If it
> continues to fail, those may be useful for us to diagnose the problem.

I just did this.  The thread starts here:

http://lists.debian.org/debian-security/2002/debian-security-200207/msg00017.html

I found no such output.

-- Dossy

-- 
Dossy Shiobara                       mail: dossy@panoptic.com 
Panoptic Computer Network             web: http://www.panoptic.com/ 
  "He realized the fastest way to change is to laugh at your own
    folly -- then you can let go and quickly move on." (p. 70)


-- 
To UNSUBSCRIBE, email to debian-security-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org