since I’ve updated my client to openSuSE 12.3, I have problems with X-Forwarding when using ssh (with -X option).
When I connect to another server with an openSuSE-Installation, there’s no problem.
But when I connect to a server, which runs SLES 11 Patchlevel 3, I can’t open any application which uses X-Server.
The errormessage is
The program '<unknown>' received an X Window System error.This probably reflects a bug in the program.
The error was '148'.
(Details: serial 46 error_code 148 request_code 140 minor_code 20)
(Note to programmers: normally, X errors are reported asynchronously;
that is, you will receive the error a while after causing it.
To debug your program, run it with the --sync command line
option to change this behavior. You can then get a meaningful
backtrace from your debugger if you break on the gdk_x_error() function.)
I cannot figure out, what’s the problem.
Can anyone help me please?
I too have this.
Nothing in my config files has changed, but my hardware has. So I kind of put it down to that. As -X isn’t that important for me, I didn’t fuss with it. I’m sure it’s on the server side, because I can -X on other servers OK.
In my case, the server is 12.3
But I can’t remember if I ever -X to 12.3 with success. It could be back as far as 12.2 that I last did it.
SO for me, it could be the move from 12.2 > 12.3
Or it could be my box hardware changed (Mobo, Graphics etc)
meenzer82 wrote:
> But when I connect to a server, which runs SLES 11 Patchlevel 3, I can’t
> open any application which uses X-Server.
>
> The errormessage is
Please show the full session, using perhaps xeyes as the program to run.
And have you done either of the steps that the message suggested?
To debug your program, run it with the --sync command line
option to change this behavior. You can then get a meaningful
backtrace from your debugger if you break on the gdk_x_error()
function.)
Interesting: xeyes works fine, but for example gedit does not
p2929@mest:~> ssh -vX pdi@etlserver
OpenSSH_6.1p1, OpenSSL 1.0.1e 11 Feb 2013
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 20: Applying options for *
debug1: Connecting to etlserver [192.168.14.151] port 22.
debug1: Connection established.
debug1: identity file /home/p2929/.ssh/id_rsa type 1
debug1: identity file /home/p2929/.ssh/id_rsa-cert type -1
debug1: identity file /home/p2929/.ssh/id_dsa type 2
debug1: identity file /home/p2929/.ssh/id_dsa-cert type -1
debug1: identity file /home/p2929/.ssh/id_ecdsa type -1
debug1: identity file /home/p2929/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.2
debug1: match: OpenSSH_6.2 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: RSA dd:52:be:a4:22:c0:45:3b:be:1b:e1:2b:1a:70:96:99
debug1: Host 'etlserver' is known and matches the RSA host key.
debug1: Found key in /home/p2929/.ssh/known_hosts:29
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/p2929/.ssh/id_rsa
debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: Offering DSA public key: /home/p2929/.ssh/id_dsa
debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: Trying private key: /home/p2929/.ssh/id_ecdsa
debug1: Next authentication method: keyboard-interactive
Password:
debug1: Authentication succeeded (keyboard-interactive).
Authenticated to etlserver ([192.168.14.151]:22).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: Requesting X11 forwarding with authentication spoofing.
debug1: Sending environment.
debug1: Sending env LANG = de_DE.UTF-8
Last login: Thu Sep 26 12:24:49 2013 from 192.168.17.14
pdi@liefernix:~> xeyes
debug1: client_input_channel_open: ctype x11 rchan 2 win 65536 max 16384
debug1: client_request_x11: request from 127.0.0.1 53144
debug1: channel 1: new [x11]
debug1: confirm x11
^C
debug1: channel 1: FORCE input drain
debug1: channel 1: free: x11, nchannels 2
pdi@liefernix:~> gedit
debug1: client_input_channel_open: ctype x11 rchan 2 win 65536 max 16384
debug1: client_request_x11: request from 127.0.0.1 53146
debug1: channel 1: new [x11]
debug1: confirm x11
The program 'gedit' received an X Window System error.
This probably reflects a bug in the program.
The error was '148'.
(Details: serial 46 error_code 148 request_code 140 minor_code 20)
(Note to programmers: normally, X errors are reported asynchronously;
that is, you will receive the error a while after causing it.
To debug your program, run it with the --sync command line
option to change this behavior. You can then get a meaningful
backtrace from your debugger if you break on the gdk_x_error() function.)
debug1: channel 1: FORCE input drain
debug1: channel 1: free: x11, nchannels 2
I didn’t change anything on the server or hardware. And it worked before I updated my client!
FWIW I just SSH’d from an openSUSE 12.3 x86_64 system to a SLES 11 SP3
x86_64 system and was able to run both xeyes and gedit. I can get exact
versions of packages if it will help… I suspect neither system is
current on patches, and the SLES system in particular is probably without
any patches, though it is does have Novell’s Open Enterprise Server 11 SP2
(beta) software on it… I highly doubt that matters for this test.