Red Hat Bugzilla – Bug 178970
X11-forwarding protocol error after upgrade
Last modified: 2007-11-30 17:11:22 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.7.12) Gecko/20050922 Fedora/1.0.7-1.1.fc4 Firefox/1.0.7
Description of problem:
After this weeks upgrade of openssh, X-forwarding from my OpenVMS machine to my Fedora box does not work anymore.
The following error message is displayed :
X11 connection rejected because of wrong authentication.
X connection to _WSA61: broken (explicit kill or server shutdown).
X Error of failed request: BadConnection (fatal error on display connection)
Major opcode of failed request: 1 (X_CreateWindow)
Serial number of failed request: 0
Current serial number in output stream: 0
%XLIB-E-ERROREVENT, error event received from server
Xlib: client uses different protocol version (11) than server (0)!
X Toolkit Error: Can't Open display
%DWT-F-NOMSG, Message number 03AB8204
The previous version dis not have any problems in this respect
When I tried a Linux machine with the update I did not see any problems
Is something being changed on X11-tunneling???
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.ssh -Y vms.machhine or ssh -X vms.machine
2.logon on VMS machine
3. Try to open a X11-session ( i.e mc decw$clock )
Actual Results: Error message
Expected Results: nice X11-window
I also tries a Fedora core 4 machine on which openssh was not upgraded:
Xlib: connection to "localhost:10.0" refused by server
Xlib: Invalid MIT-MAGIC-COOKIE-1 key
Error: Can't open display: :10
I'm sorry but I'm unable to reproduce this problem ssh -X (or -Y) from FC4
machine with openssh-4.2p1-fc4.10 to a machine with openssh-4.2p1-fc4.1.
I don't have OpenVMS for testing so I cannot verify that it works/doesn't work
with it here.
Can you provide logs from 'ssh -vvv -X vms.machine'?
Created attachment 123707 [details]
Log file of ssh with X-forwarding to OpenVMS system
I'm not so sure about the connection to the fedora system. mayby I mixed up the
server number (10<->11). But VMS is a real problem.
I attached the log file of the session to a VMS machine.
Tomas if you want to try yourself on a VMS machine, contact me on my E-mail adres.
Could you try to downgrade the openssh back to 4.2p1-fc4.1 version?
It seems like the problem is on the OpenVMS side - like if the .Xauthority file
is not created or is unaccessible.
Also are you able to run X applications from the command line from which you
call the ssh to the server? And what prints 'xauth list' on the client and then
on the server machine?
>Could you try to downgrade the openssh back to 4.2p1-fc4.1 version?
Will try later today
>It seems like the problem is on the OpenVMS side - like if the .Xauthority file
>is not created or is unaccessible.
On vms it is called : decw$xauthority.decw$xauth
it exists and should be accessible
On linux the .Xauthority is peresent
>Also are you able to run X applications from the command line from which you
>call the ssh to the server?
I'm not sure what you mean. In the example log file I gave the command to run
the clock program from the command line. Is that what you want???
>And what prints 'xauth list' on the client and then
>on the server machine?
on VMS :
sirba-jj) mc decw$xauth list
184.108.40.206:10 MIT-MAGIC-COOKIE-1 e83eeede199bd8bb7b139fa7688e444e
220.127.116.11:10 MIT-MAGIC-COOKIE-1 80d1d9c69f66756b0068ff8d1d181c13
18.104.22.168:10 MIT-MAGIC-COOKIE-1 da20b587f2f627bd199dddc06cfa607e
22.214.171.124:11 MIT-MAGIC-COOKIE-1 d358275dfbdc79900679df063616a10c
126.96.36.199:11 MIT-MAGIC-COOKIE-1 653ef0080d0440e1c9ad0bf480a2501a
188.8.131.52:12 MIT-MAGIC-COOKIE-1 a2a76814ba3e81b45ed3402229c311d3
hrem157:10 MIT-MAGIC-COOKIE-1 59feb31e598d3e6e02dda3401243ce5b
hrem172:10 MIT-MAGIC-COOKIE-1 618664db25bf35ec89a53ca9a717aab4
hrem174:10 MIT-MAGIC-COOKIE-1 d13ec8c1a3cd9e9b96029823d451d7a8
note that hrem157 is the linux machine on which I gave the command ssh -Y
on linux when the connection is on:
aaee-jj ) xauth list
tarantella/unix:12 MIT-MAGIC-COOKIE-1 25dba4460ca215860701941c613798a3
tarantella/unix:11 MIT-MAGIC-COOKIE-1 95d170734ce4f6a75ab1a3153f426fa8
tarantella/unix:0 MIT-MAGIC-COOKIE-1 faf882d8366e0d6af7614a182a88554d
localhost.localdomain/unix:0 MIT-MAGIC-COOKIE-1 faf882d8366e0d6af7614a182a88554d
tarantella/unix:10 MIT-MAGIC-COOKIE-1 605c783c1bc6aa6114262f64b07ea32e
note that the VMS machine is not in this list.
Is the hrem157:10 line changing when you're trying to ssh login repeatedly?
Not changing. I renamed the decw$xauthority.decw$xauth
and did a mc decw$xauth list.
It tells me it is creating a new file but it does not.
Seems a problem on VMS. I'll call HP (we have a service contract for this machine)
I'll let you know about the results
I got it working again. It seemed that the decw$xauthority.decw$xauth was corrupt
and that no when removed no new one was generated : I copied one from another
user and everything works again. I have no idea what caused it since I di not do
any upgrades or wathever on the VMS machine over the last week.