I had this problem as well, but didn't need it bad enough until I started
reading this thread and decided to look into it more.
1: make sure <server>/etc/ssh/sshd_config has Xforwarding enabled "yes"
2: make sure you have "xbase-clients" installed, it contains the xauth program.
3: run ssh with "-X" on the command line or edit ssh_config to always turn
on X forwarding.
This worked for me between 2 woody boxes. One is a server with no need for
X on it's console so I didn't have the xbase-clients package installed and
didn't see the problem untill running "ssh -v -X" and reading the output...
Hope this helps,
Loren
At 07:58 PM 7/1/2002 -0400, Dossy wrote:
On 2002.07.01, Vineet Kumar <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
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 [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]