Bug 178970 - X11-forwarding protocol error after upgrade
X11-forwarding protocol error after upgrade
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: openssh (Show other bugs)
4
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Tomas Mraz
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-01-25 16:05 EST by J.Jansen
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-01-26 07:01:32 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Log file of ssh with X-forwarding to OpenVMS system (13.47 KB, text/plain)
2006-01-26 02:46 EST, J.Jansen
no flags Details

  None (edit)
Description J.Jansen 2006-01-25 16:05:12 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):
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 16:17:47 EST
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 18:55:47 EST
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 02:46:05 EST
Created attachment 123707 [details]
Log file of ssh with X-forwarding to OpenVMS system
Comment 4 J.Jansen 2006-01-26 02:46:34 EST
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 04:27:10 EST
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 04:57:37 EST
>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 05:20:13 EST
Is the hrem157:10 line changing when you're trying to ssh login repeatedly?
Comment 8 J.Jansen 2006-01-26 05:28:15 EST
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 06:00:30 EST
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 07:01:32 EST
NOTABUG then.

Note You need to log in before you can comment on or make changes to this bug.