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): openssh-4.2p1-fc4.10 How reproducible: Always 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 Additional info:
I also tries a Fedora core 4 machine on which openssh was not upgraded: result : fer-jj) xclock 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. Jouk
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 130.161.241.205:10 MIT-MAGIC-COOKIE-1 e83eeede199bd8bb7b139fa7688e444e 130.161.241.120:10 MIT-MAGIC-COOKIE-1 80d1d9c69f66756b0068ff8d1d181c13 130.161.240.10:10 MIT-MAGIC-COOKIE-1 da20b587f2f627bd199dddc06cfa607e 130.161.241.120:11 MIT-MAGIC-COOKIE-1 d358275dfbdc79900679df063616a10c 130.161.241.205:11 MIT-MAGIC-COOKIE-1 653ef0080d0440e1c9ad0bf480a2501a 130.161.241.120: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.
NOTABUG then.