X gurus: Xlib:connection refused, invalid magic cookie
I try to set up a distributed X computing environment on a network envolving 3 hosts and need some advice from some X gurus: Configuration: -------------- hostA runs my local X server (X display where I sit working) hostB runs my remote Window Manager (GDM login&session host) hostC runs my remote X client application (execution host) HostA is set up to boot directly into X mode querying and presenting the login screen from hostB (like a X terminal without local login first). HostB and HostC have both individual home directories and passwd for the same users, and both use /etc/hosts and /etc/hosts.equiv. Command dialog: --------------- On hostA I log in to hostB and enter the following commands: hostB-> xhost hostC hostB-> rlogin hostC hostC % setenv DISPLAY hostA:0 hostC % XclientApp The following typical error messages are displayed and theXclientApp doesn't start up or is not displayed on hostA: Xlib: connection to hostA:0 refused by the server Xlib: Invalid MIT-MAGIC-COOKIE-1 key A rlogin to hostA also confirmed that: X: client is rejected from IP_of_hostA Problem: -------- I think the problem is the user access authorisation, that is how to tell the X server on hostA to allow connections also from hostC (X apps) in addition to the connected Windows Manager from hostB. Therefore I also tried first: hostB-> rlogin hostA hostA % xhost hostC which only resulted in the following error message: unable to open display "" Now I need advice from some X gurus? Terje J. Hanssen
onsdag 18 februari 2004 02:23 skrev Terje J. Hanssen:
Command dialog: --------------- On hostA I log in to hostB and enter the following commands:
hostB-> xhost hostC hostB-> rlogin hostC
Now you are telling hostB, that it should allow connections FROM hostC.
hostC % setenv DISPLAY hostA:0 hostC % XclientApp
Have you done: hostA-> xhost hostC which is needed for the above.
hostB-> rlogin hostA hostA % xhost hostC which only resulted in the following error message: unable to open display ""
rlogin to another machine, does not give you control over that machines X server. Which is what you are attempting to do. To be able to do the above, you must be the owner, or user of that hosts X server. That is, the one logged in to that machine, otherwise you cannot tell that X, to accept connections from anywhere. Only the user of that session, has that right. Given, that you are logged in on the workstation hostA, directly: hostA-> xhost hostB hostA-> rlogin hostB hostB-> export DISPLAY=hostA:0 hostB-> xterm Will run an xterm on hostB, and show the window up on hostA. --- And now, for simplifications. Abandon the r-commands, they are insecure and not used anymore. hostA-> ssh -X hostB hostB-> xterm Will do the same thing, as earlier ... of course, in this situation you will have to type a password, assuming you have a distributed /home directories accross your network, where all workstation will have the same /home for each user, wherever they are logged in: hostA-> ssh-keygen -t rsa ; no passphrase hostA-> cat .ssh/id_rsa.pub >>.ssh/authorized_keys2 hostA-> ssh -X hostB ; just as if rlogin hostB-> xterm And remove all references to ssh v1 in the sshd.conf file, as well as allowing passwords to be sent. Use keys only, with or without a passphrase.
I have the same problem, and after downloading the file in the patch "xf86tools.rpm" and installing it the situation has not improved... any suggestion? regards, Riccardo Facchini
On Sat, 2004-01-31 at 17:34, Anders Johansson wrote:
On Saturday 31 January 2004 18.20, Peter Onion wrote:
Thanks for the reply.
I do get that key, but also another one. Should I get only one ?
No, there's also a suse-security key, but the suse->>build-key seems to be the important one, at least in my trials.
OK, if you have that key installed in rpm, then your problem must be something else. Try downloading the packages manually and install them from the command line and see if that works
It's not a package, it's a patch...
I've downloaded the patch, how do I verify the signature in it ?
Peter
===== Riccardo G. Facchini
Maybe I'm completely wrong and I missed something on my local copy.... but I had to remove this list of patches from the local copy of the ftp.suse.com/pub/suse/i386/update/9.0/patches xf86tools-44811 openssl-44810 fetchmsttfonts-3 fetchnvidia-1 lsh-45738 cron-45929 jpilot-Backup-45933 jpilot-45934 openssh-45935 spamassassin-45937 mpg123-46045 bluez-bluefw-46146 tsclient-46151 sylpheed-46440 yast2-storage-46544 cipe-46660 kdebase3-46893 gnucash-46921 kbd-46924 libnids-47695 thttpd-47696 ei-47840 yast2-packagemanager-47846 koffice-47882 SuSEfirewall2-48273 saint-48280 coreutils-48558 hylafax-49197 sysconfig-49356 qt3-49495 gdm2-50409 ircd-50410 kdelibs3-50411 pinentry-50412 suselinux-userguide_de-50413 suselinux-userguide_en-50414 xscreensaver-51145 ganglia-monitor-core-51146 apache-51151 apache2-51152 bastille-51158 gpg-51150 unace-51181 rsync-51182 screen-51184 perl-51189 lftp-51190 freeradius-51162 irssi-51192 memprof-51203 kopete-51211 fontconfig-51193 cdrecord-51194 tcpd-51160 kernel-51204 kernel-source-51200 pin-51212 inn-51220 mpg321-51224 popper-51196 kdepim3-51195 opera-51217 tcpdump-51216 cvs-51201 gnome-filesystem-51225 ethereal-51205 cvsup-51227 3ddiag-51213 quagga-51230 mc-51223 python-51214 ltmodem-51236 gtk2-51238 XFree86-51218 tcpdump-51228 netpbm-51240 cups-51246 gaim-51248 whois-51247 In order to have YOU end the update. I'm sure I'm doing something wrong, but I don't know what! can somebody help me please? regards, --- abief_ag_-suseml@yahoo.com wrote:
I have the same problem, and after downloading the file in the patch "xf86tools.rpm" and installing it the situation has not improved...
any suggestion?
regards,
Riccardo Facchini
On Sat, 2004-01-31 at 17:34, Anders Johansson wrote:
On Saturday 31 January 2004 18.20, Peter Onion wrote:
Thanks for the reply.
I do get that key, but also another one. Should I get only one ?
No, there's also a suse-security key, but the suse->>build-key seems to be the important one, at least in my trials.
OK, if you have that key installed in rpm, then your problem must be something else. Try downloading the packages manually and install them from the command line and see if that works
It's not a package, it's a patch...
I've downloaded the patch, how do I verify the signature in it ?
Peter
===== Riccardo G. Facchini
-- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com
===== Riccardo G. Facchini
Örn Hansen
onsdag 18 februari 2004 02:23 skrev Terje J. Hanssen:
Command dialog: --------------- On hostA I log in to hostB and enter the following commands:
hostB-> xhost hostC hostB-> rlogin hostC
Now you are telling hostB, that it should allow connections FROM hostC.
hostC % setenv DISPLAY hostA:0 hostC % XclientApp
Have you done:
hostA-> xhost hostC
which is needed for the above.
No, this cannot work since clients from hostA are not authorized to connect to the X server. What he needs to do is to copy the MIT-MAGIC-COOKIE-1 generated by GDM on hostB (and stored in the ~/.Xauthority file there) to hostC.
hostB-> rlogin hostA hostA % xhost hostC which only resulted in the following error message: unable to open display ""
rlogin to another machine, does not give you control over that machines X server. Which is what you are attempting to do. To be able to do the above, you must be the owner, or user of that hosts X server.
If I understand the sentence right then it is not true. XDM sessions work in a different way.
That is, the one logged in to that machine, otherwise you cannot tell that X, to accept connections from anywhere. Only the user of that session, has that right.
Given, that you are logged in on the workstation hostA, directly:
hostA-> xhost hostB hostA-> rlogin hostB hostB-> export DISPLAY=hostA:0 hostB-> xterm
Will run an xterm on hostB, and show the window up on hostA.
Note that he runs XDM session on hostB from an X server on hostA. In other words: he is NOT logged in on hostA. -- A.M.
onsdag 18 februari 2004 23:55 skrev Alexandr Malusek:
No, this cannot work since clients from hostA are not authorized to connect to the X server. What he needs to do is to copy the MIT-MAGIC-COOKIE-1 generated by GDM on hostB (and stored in the ~/.Xauthority file there) to hostC.
Never copy the cookie, use xhost.
If I understand the sentence right then it is not true. XDM sessions work in a different way.
Your understanding is wrong.
Note that he runs XDM session on hostB from an X server on hostA. In other words: he is NOT logged in on hostA.
It's irrelevant, how he runs his XDM ... it's the X server in charge, that is the concern. Even if you are logged into hostB, from hostA, you are not logged into hostB and cannot take over the session of the user on workstation hostB, simply because you're on a remote xdm session. That would be a serious security flaw, if it were possible.
"Terje J. Hanssen"
I try to set up a distributed X computing environment on a network envolving 3 hosts and need some advice from some X gurus:
Configuration: -------------- hostA runs my local X server (X display where I sit working) hostB runs my remote Window Manager (GDM login&session host) hostC runs my remote X client application (execution host)
HostA is set up to boot directly into X mode querying and presenting the login screen from hostB (like a X terminal without local login first). HostB and HostC have both individual home directories and passwd for the same users, and both use /etc/hosts and /etc/hosts.equiv.
Command dialog: --------------- On hostA I log in to hostB and enter the following commands:
hostB-> xhost hostC hostB-> rlogin hostC
hostC % setenv DISPLAY hostA:0 hostC % XclientApp
The following typical error messages are displayed and theXclientApp doesn't start up or is not displayed on hostA:
Xlib: connection to hostA:0 refused by the server Xlib: Invalid MIT-MAGIC-COOKIE-1 key
Your steps make sense but, apparently, the host access control mechanism is not considered. You can check that it is enabled by running (the output is from my local KDE session) hostB-> xhost access control enabled, only authorized clients can connect Anyway, you can copy the MIT-MAGIC-COOKIE-1 from hostB to hostC via the xauth command, see the example in "man xauth".
hostB-> rlogin hostA hostA % xhost hostC
This cannot work since clients on hostA (e.g. the command xhost) are not authorized to connect to the server. Anyway, "ssh -X" may make your life easier since it handles the authorization issues automatically. -- A.M.
participants (5)
-
abief_ag_-suseml＠yahoo.com -
Alexandr Malusek -
Riccardo Facchini
-
Terje J. Hanssen -
Örn Hansen