X11 forwarding problem with certain accounts on Fedora

I have recently noticed an X11 problem with certain users accounts on Fedora 4/5 machines. I have a small network with NIS authentication and a variety of Sun, SGI, Linux, Mac and Windows systems. For most system, if I log onto one of my servers X11 works fine. However, in the last week I have noticed two accounts can no longer do X11 forwarding when on a fedora 4 or 5 machine. If you set “xhost +” first or set your environment variable afterwards, it sill doesn’t work. Interestingly, those same account will work fine logging in from a MAC or Sun.

Here are the verbose ssh outputs for an account that works and an account that fails logging in to an SGI server (IRIX 6.2.5) from a fedora core 4 machine.

Thanks in advance!

##############FailedAccount################################
# ssh -v -X $server$ -l $baduseraccountname$
OpenSSH_4.2p1, OpenSSL 0.9.7f 22 Mar 2005
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to 128.147.59.100 [128.147.59.100] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/identity type -1
debug1: identity file /root/.ssh/id_rsa type -1
debug1: identity file /root/.ssh/id_dsa type -1
debug1: Remote protocol version 1.99, remote software version OpenSSH_3.4p1
debug1: match: OpenSSH_3.4p1 pat OpenSSH_3.*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.2
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host '$server$' is known and matches the RSA host key.
debug1: Found key in /root/.ssh/known_hosts:4
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password,keyboard-interacti ve
debug1: Next authentication method: publickey
debug1: Trying private key: /root/.ssh/identity
debug1: Trying private key: /root/.ssh/id_rsa
debug1: Trying private key: /root/.ssh/id_dsa
debug1: Next authentication method: keyboard-interactive
debug1: Authentications that can continue: publickey,password,keyboard-interacti ve
debug1: Next authentication method: password
$baduseraccountname$@$server$'s password:
debug1: Authentication succeeded (password).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: Requesting X11 forwarding with authentication spoofing.
Last login: Fri Apr  7 08:25:28 2006 from
debug1: client_input_channel_open: ctype x11 rchan 2 win 65536 max 16384
debug1: client_request_x11: request from 127.0.0.1 39412
debug1: channel 1: new [x11]
debug1: confirm x11
debug1: channel 1: FORCE input drain
debug1: channel 1: free: x11, nchannels 2
debug1: client_input_channel_open: ctype x11 rchan 2 win 65536 max 16384
debug1: client_request_x11: request from 127.0.0.1 21209
debug1: channel 1: new [x11]
debug1: confirm x11
xset:  bad font path element (#64), possible causes are:
    Directory does not exist or has wrong permissions
    Directory missing fonts.dir
    Incorrect font server address or syntax
debug1: channel 1: FORCE input drain
debug1: channel 1: free: x11, nchannels 2
debug1: client_input_channel_open: ctype x11 rchan 2 win 65536 max 16384
debug1: client_request_x11: request from 127.0.0.1 39019
debug1: channel 1: new [x11]
debug1: confirm x11
debug1: channel 1: FORCE input drain
xset:  bad font path element (#64), possible causes are:
    Directory does not exist or has wrong permissions
    Directory missing fonts.dir
    Incorrect font server address or syntax
debug1: channel 1: free: x11, nchannels 2
debug1: client_input_channel_open: ctype x11 rchan 2 win 65536 max 16384
debug1: client_request_x11: request from 127.0.0.1 31653
debug1: channel 1: new [x11]
debug1: confirm x11
debug1: channel 1: FORCE input drain
debug1: channel 1: free: x11, nchannels 2
~> xclock
Error: Can't open display: 0
~> setenv DISPLAY $myIP$:0.0
~> xclock
Error: Can't open display: $myIP$:0.0
logout
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: channel 0: free: client-session, nchannels 1
Connection to $server$ closed.
debug1: Transferred: stdin 0, stdout 0, stderr 38 bytes in 131.0 seconds
debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.3
debug1: Exit status 0


#############Good Account##################################
# ssh -v -X $server$ -l $gooduseraccountname$
OpenSSH_4.2p1, OpenSSL 0.9.7f 22 Mar 2005
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to $server$ [$server$] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/identity type -1
debug1: identity file /root/.ssh/id_rsa type -1
debug1: identity file /root/.ssh/id_dsa type -1
debug1: Remote protocol version 1.99, remote software version OpenSSH_3.4p1
debug1: match: OpenSSH_3.4p1 pat OpenSSH_3.*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.2
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host '$server$' is known and matches the RSA host key.
debug1: Found key in /root/.ssh/known_hosts:4
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Trying private key: /root/.ssh/identity
debug1: Trying private key: /root/.ssh/id_rsa
debug1: Trying private key: /root/.ssh/id_dsa
debug1: Next authentication method: keyboard-interactive
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: password
$gooduseraccountname$@$server$ password:
debug1: Authentication succeeded (password).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: Requesting X11 forwarding with authentication spoofing.
Last login: Fri Apr  7 08:13:18 2006 from
~>
~> xclock
debug1: client_input_channel_open: ctype x11 rchan 2 win 65536 max 16384
debug1: client_request_x11: request from 127.0.0.1 33882
debug1: channel 1: new [x11]
debug1: confirm x11
Warning: Color name "sgislateblue" is not defined
debug1: channel 1: FORCE input drain
doctorspearsAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

ahoffmannCommented:
did you check the user's ~/.ssh/config file
sound like the baduseraccount disabled X-forwarding
Also: does yur $SSH_CLIENT contain the IP you want to set your $DISPLAY too?
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
doctorspearsAuthor Commented:
- All the ssh config files have X11 forwarding enabled.
- "xhost +" doesn't make a difference.
- Even setting the server as a host doesnt help.

If I try and use "goodaccount" I can forward X11 from any system (linux, Mac, Sun, SGI). If I am using "badaccount" I can still forward X11 from a MAC, a Sun or an SGI, but not from ANY of my fedora core 4/5 systems.
0
ahoffmannCommented:
> .. ANY of my fedora core 4/5 systems.
is there a firewall/packetfilter active, which blocks 600x ports?

Why not using ssh's X-tunnel, ist's usually used like:
   DISPLAY=ip.ip.ip.ip:10

see man ssh
0
Cloud Class® Course: CompTIA Healthcare IT Tech

This course will help prep you to earn the CompTIA Healthcare IT Technician certification showing that you have the knowledge and skills needed to succeed in installing, managing, and troubleshooting IT systems in medical and clinical settings.

gheistCommented:

~> setenv DISPLAY $myIP$:0.0
~> xclock
Error: Can't open display: $myIP$:0.0

This notes that X11 forwarding of ssh did not take place

look at /etc/ssh/sshd_config

and make sure it has line
X11Forwarding yes

If you made change do /etc/init.d/sshd restart

Now try again.
0
doctorspearsAuthor Commented:
*X11 forwarding IS turned on in the sshd config file

*All firewalls are disabled

In the "badaccount" from any fedora system:
SSH -X doesn't work for X11 tunneling
SSH -Y doesn't work for X11 tunneling
rlogin doesn't work for X11 tunneling

In the "goodaccount" from ANY system or the "badaccount" from a Mac, Sun or SGI
SSH -X DOES work for X11 tunneling
SSH -Y DOES work for X11 tunneling
rlogin DOES work for X11 tunneling
0
ahoffmannCommented:
> *X11 forwarding IS turned on in the sshd config file
sshd config (sshd_config) is server-side, we spoke of the client-side config file
just to be clear

> debug1: channel 1: FORCE input drain
> xset:  bad font path element (#64), possible causes are:
>     Directory does not exist or has wrong permissions
>     Directory missing fonts.dir
>     Incorrect font server address or syntax

on which side is xset started? is it started through your .profile or whatever on the remote side?
0
gheistCommented:
Me again on same
> Error: Can't open display: $myIP$:0.0

ssh -X or -Y should take $DISPLAY that was set before running ssh and forward X11 over encrypted channel, no firewall can break after connection. DISPLAY on remote should look like :10.0 and up.

look at ~baduser/.ssh/config

if it does NOT enable ForwardX11, then it disables X11 forwarding even if set in /etc/ssh/ssh_config

0
gheistCommented:
No comment has been added to this question in more than 21 days, so it is now classified as abandoned.
I will leave the following recommendation for this question in the Cleanup topic area:

Accept ahoffmann http:#16402191

Any objections should be posted here in the next 4 days. After that time, the question will be closed.

gheist
EE Cleanup Volunteer
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Unix OS

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.