Bug 178970

Summary: X11-forwarding protocol error after upgrade
Product: [Fedora] Fedora Reporter: J.Jansen <joukj>
Component: opensshAssignee: Tomas Mraz <tmraz>
Status: CLOSED NOTABUG QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 4   
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-01-26 12:01:32 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Log file of ssh with X-forwarding to OpenVMS system none

Description J.Jansen 2006-01-25 21:05:12 UTC
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:

Comment 1 J.Jansen 2006-01-25 21:17:47 UTC
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




Comment 2 Tomas Mraz 2006-01-25 23:55:47 UTC
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'?


Comment 3 J.Jansen 2006-01-26 07:46:05 UTC
Created attachment 123707 [details]
Log file of ssh with X-forwarding to OpenVMS system

Comment 4 J.Jansen 2006-01-26 07:46:34 UTC
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

Comment 5 Tomas Mraz 2006-01-26 09:27:10 UTC
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?


Comment 6 J.Jansen 2006-01-26 09:57:37 UTC
>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.




Comment 7 Tomas Mraz 2006-01-26 10:20:13 UTC
Is the hrem157:10 line changing when you're trying to ssh login repeatedly?


Comment 8 J.Jansen 2006-01-26 10:28:15 UTC
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

Comment 9 J.Jansen 2006-01-26 11:00:30 UTC
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.

Comment 10 Tomas Mraz 2006-01-26 12:01:32 UTC
NOTABUG then.