Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1049
  • Last Modified:

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
0
doctorspears
Asked:
doctorspears
  • 3
  • 3
  • 2
1 Solution
 
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
 
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
Independent Software Vendors: We Want Your Opinion

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 
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

Featured Post

Technology Partners: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

  • 3
  • 3
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now