0
Waiting for information

X11 connection rejected because of wrong authentication

swimboy 3 years ago updated by Ben Pinkert 2 years ago 8

Just installed the latest 6.1 client on a new, fully updated CentOS 7 server. Whenever the screenconnect agent is running and an SSH session with X11 forwarding is established, the error message "X11 connection rejected because of wrong authentication" appears five times every 2-3 seconds. I don't remember having this problem with earlier versions of the agent, but I haven't updated any of my other linux agents to 6.1 yet.

ConnectWise Control Version:
Server Affected:
Host Client Affected:
Guest Client Affected:
Waiting for information

Good morning,


Thank you for submitting this information. I was unable to reproduce this behavior by connecting to a CentOS 7 server using a 6.1.12292 client after establishing an SSH session with X11 forwarding to the same endpoint.


When you say "Whenever the screenconnect agent is running", do you mean the client service is running or that you have an active ScreenConnect session going to the CentOS server?


Please update this thread with the information returned by executing the following command on the CentOS 7 endpoint (after subbing in your server's public thumbprint for the x's):


tail -200 /var/log/screenconnect-xxxxxxxxxxxxxxxx


Regards,

Ben

The problem is present whenever the client service is running, regardless of whether there is an active session or not.


Here's the tail of the log file:


2017-02-09 13:44:32.616 -0500 Exception:

java.io.EOFException

at java.io.DataInputStream.readByte(DataInputStream.java:267)

at com.screenconnect.MessageSerializer.deserialize(MessageSerializer.java:97)

at com.screenconnect.EndPointManager.receiveMessage(EndPointManager.java:121)

at com.screenconnect.EndPointManager$SocketEndPointManager.runIncomingThread(EndPointManager.java:319)

at com.screenconnect.EndPointManager$SocketEndPointManager.access$100(EndPointManager.java:133)

at com.screenconnect.EndPointManager$SocketEndPointManager$1.run(EndPointManager.java:197)

at java.lang.Thread.run(Thread.java:745)

2017-02-09 14:03:50.694 -0500 Exception:

java.io.EOFException

at java.io.DataInputStream.readByte(DataInputStream.java:267)

at com.screenconnect.MessageSerializer.deserialize(MessageSerializer.java:97)

at com.screenconnect.EndPointManager.receiveMessage(EndPointManager.java:121)

at com.screenconnect.EndPointManager$SocketEndPointManager.runIncomingThread(EndPointManager.java:319)

at com.screenconnect.EndPointManager$SocketEndPointManager.access$100(EndPointManager.java:133)

at com.screenconnect.EndPointManager$SocketEndPointManager$1.run(EndPointManager.java:197)

at java.lang.Thread.run(Thread.java:745)

2017-02-09 14:04:33.878 -0500 Exception:

java.io.EOFException

at java.io.DataInputStream.readByte(DataInputStream.java:267)

at com.screenconnect.MessageSerializer.deserialize(MessageSerializer.java:97)

at com.screenconnect.EndPointManager.receiveMessage(EndPointManager.java:121)

at com.screenconnect.EndPointManager$SocketEndPointManager.runIncomingThread(EndPointManager.java:319)

at com.screenconnect.EndPointManager$SocketEndPointManager.access$100(EndPointManager.java:133)

at com.screenconnect.EndPointManager$SocketEndPointManager$1.run(EndPointManager.java:197)

at java.lang.Thread.run(Thread.java:745)

2017-02-09 14:04:48.635 -0500 Exception:

java.io.EOFException

at java.io.DataInputStream.readByte(DataInputStream.java:267)

at com.screenconnect.MessageSerializer.deserialize(MessageSerializer.java:97)

at com.screenconnect.EndPointManager.receiveMessage(EndPointManager.java:121)

at com.screenconnect.EndPointManager$SocketEndPointManager.runIncomingThread(EndPointManager.java:319)

at com.screenconnect.EndPointManager$SocketEndPointManager.access$100(EndPointManager.java:133)

at com.screenconnect.EndPointManager$SocketEndPointManager$1.run(EndPointManager.java:197)

at java.lang.Thread.run(Thread.java:745)

2017-02-09 14:05:49.902 -0500 Exception:

java.io.EOFException

at java.io.DataInputStream.readByte(DataInputStream.java:267)

at com.screenconnect.MessageSerializer.deserialize(MessageSerializer.java:97)

at com.screenconnect.EndPointManager.receiveMessage(EndPointManager.java:121)

at com.screenconnect.EndPointManager$SocketEndPointManager.runIncomingThread(EndPointManager.java:319)

at com.screenconnect.EndPointManager$SocketEndPointManager.access$100(EndPointManager.java:133)

at com.screenconnect.EndPointManager$SocketEndPointManager$1.run(EndPointManager.java:197)

at java.lang.Thread.run(Thread.java:745)

2017-02-09 14:07:21.902 -0500 Exception:

java.io.EOFException

at java.io.DataInputStream.readByte(DataInputStream.java:267)

at com.screenconnect.MessageSerializer.deserialize(MessageSerializer.java:97)

at com.screenconnect.EndPointManager.receiveMessage(EndPointManager.java:121)

at com.screenconnect.EndPointManager$SocketEndPointManager.runIncomingThread(EndPointManager.java:319)

at com.screenconnect.EndPointManager$SocketEndPointManager.access$100(EndPointManager.java:133)

at com.screenconnect.EndPointManager$SocketEndPointManager$1.run(EndPointManager.java:197)

at java.lang.Thread.run(Thread.java:745)

2017-02-09 14:07:49.172 -0500 Exception:

java.io.EOFException

at java.io.DataInputStream.readByte(DataInputStream.java:267)

at com.screenconnect.MessageSerializer.deserialize(MessageSerializer.java:97)

at com.screenconnect.EndPointManager.receiveMessage(EndPointManager.java:121)

at com.screenconnect.EndPointManager$SocketEndPointManager.runIncomingThread(EndPointManager.java:319)

at com.screenconnect.EndPointManager$SocketEndPointManager.access$100(EndPointManager.java:133)

at com.screenconnect.EndPointManager$SocketEndPointManager$1.run(EndPointManager.java:197)

at java.lang.Thread.run(Thread.java:745)

2017-02-09 14:08:19.649 -0500 Exception:

java.io.EOFException

at java.io.DataInputStream.readByte(DataInputStream.java:267)

at com.screenconnect.MessageSerializer.deserialize(MessageSerializer.java:97)

at com.screenconnect.EndPointManager.receiveMessage(EndPointManager.java:121)

at com.screenconnect.EndPointManager$SocketEndPointManager.runIncomingThread(EndPointManager.java:319)

at com.screenconnect.EndPointManager$SocketEndPointManager.access$100(EndPointManager.java:133)

at com.screenconnect.EndPointManager$SocketEndPointManager$1.run(EndPointManager.java:197)

at java.lang.Thread.run(Thread.java:745)

Exception in thread "ShutdownHook" java.awt.AWTError: Can't connect to X11 window server using 'localhost:10.0' as the value of the DISPLAY variable.

at sun.awt.X11GraphicsEnvironment.initDisplay(Native Method)

at sun.awt.X11GraphicsEnvironment.access$200(X11GraphicsEnvironment.java:65)

at sun.awt.X11GraphicsEnvironment$1.run(X11GraphicsEnvironment.java:115)

at java.security.AccessController.doPrivileged(Native Method)

at sun.awt.X11GraphicsEnvironment.<clinit>(X11GraphicsEnvironment.java:74)

at java.lang.Class.forName0(Native Method)

at java.lang.Class.forName(Class.java:264)

at java.awt.GraphicsEnvironment.createGE(GraphicsEnvironment.java:103)

at java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment(GraphicsEnvironment.java:82)

at sun.awt.X11.XToolkit.<clinit>(XToolkit.java:126)

at java.lang.Class.forName0(Native Method)

at java.lang.Class.forName(Class.java:264)

at java.awt.Toolkit$2.run(Toolkit.java:860)

at java.awt.Toolkit$2.run(Toolkit.java:855)

at java.security.AccessController.doPrivileged(Native Method)

at java.awt.Toolkit.getDefaultToolkit(Toolkit.java:854)

at sun.swing.SwingUtilities2.getSystemMnemonicKeyMask(SwingUtilities2.java:2020)

at javax.swing.plaf.basic.BasicLookAndFeel.initComponentDefaults(BasicLookAndFeel.java:1158)

at javax.swing.plaf.metal.MetalLookAndFeel.initComponentDefaults(MetalLookAndFeel.java:431)

at javax.swing.plaf.basic.BasicLookAndFeel.getDefaults(BasicLookAndFeel.java:148)

at javax.swing.plaf.metal.MetalLookAndFeel.getDefaults(MetalLookAndFeel.java:1577)

at javax.swing.UIManager.setLookAndFeel(UIManager.java:539)

at javax.swing.UIManager.setLookAndFeel(UIManager.java:579)

at javax.swing.UIManager.initializeDefaultLAF(UIManager.java:1349)

at javax.swing.UIManager.initialize(UIManager.java:1459)

at javax.swing.UIManager.maybeInitialize(UIManager.java:1426)

at javax.swing.UIManager.getDefaults(UIManager.java:659)

at javax.swing.UIManager.getString(UIManager.java:788)

at javax.swing.filechooser.UnixFileSystemView.<clinit>(FileSystemView.java:610)

at javax.swing.filechooser.FileSystemView.getFileSystemView(FileSystemView.java:86)

at com.screenconnect.client.ClientOSToolkit.getScreenConnectDirectoryForUser(ClientOSToolkit.java:134)

at com.screenconnect.client.ClientOSToolkit$UnixClientToolkit.getScreenConnectDirectoryForUser(ClientOSToolkit.java:171)

at com.screenconnect.client.ClientFileTransferHandler.getBaseDirectory(ClientFileTransferHandler.java:25)

at com.screenconnect.FileTransferHandler.getDirectory(FileTransferHandler.java:9)

at com.screenconnect.FileTransferHandler.ensureCleanedUp(FileTransferHandler.java:17)

at com.screenconnect.client.ClientService.ensureCleanedUp(ClientService.java:114)

at com.screenconnect.client.Program$MainAction$2$1.run(Program.java:134)

at java.lang.Thread.run(Thread.java:745)


Good morning,


Thank you submitting the log contents for review. What version of Java is active on the CentOS 7 server? Also, would you mind submitting the contents of your sshd_config?


Cheers,

Ben

I'm running java-1.8.0-openjdk.x86_64


Here's my sshd_config, I don't believe I've made any changes from the default configuration:


# $OpenBSD: sshd_config,v 1.93 2014/01/10 05:59:19 djm Exp $

# This is the sshd server system-wide configuration file. See

# sshd_config(5) for more information.

# This sshd was compiled with PATH=/usr/local/bin:/usr/bin

# The strategy used for options in the default sshd_config shipped with

# OpenSSH is to specify options with their default value where

# possible, but leave them commented. Uncommented options override the

# default value.

# If you want to change the port on a SELinux system, you have to tell

# SELinux about this change.

# semanage port -a -t ssh_port_t -p tcp #PORTNUMBER

#

#Port 22

#AddressFamily any

#ListenAddress 0.0.0.0

#ListenAddress ::

# The default requires explicit activation of protocol 1

#Protocol 2

# HostKey for protocol version 1

#HostKey /etc/ssh/ssh_host_key

# HostKeys for protocol version 2

HostKey /etc/ssh/ssh_host_rsa_key

#HostKey /etc/ssh/ssh_host_dsa_key

HostKey /etc/ssh/ssh_host_ecdsa_key

HostKey /etc/ssh/ssh_host_ed25519_key

# Lifetime and size of ephemeral version 1 server key

#KeyRegenerationInterval 1h

#ServerKeyBits 1024

# Ciphers and keying

#RekeyLimit default none

# Logging

# obsoletes QuietMode and FascistLogging

#SyslogFacility AUTH

SyslogFacility AUTHPRIV

#LogLevel INFO

# Authentication:

#LoginGraceTime 2m

#PermitRootLogin yes

#StrictModes yes

#MaxAuthTries 6

#MaxSessions 10

#RSAAuthentication yes

#PubkeyAuthentication yes

# The default is to check both .ssh/authorized_keys and .ssh/authorized_keys2

# but this is overridden so installations will only check .ssh/authorized_keys

AuthorizedKeysFile .ssh/authorized_keys

#AuthorizedPrincipalsFile none

#AuthorizedKeysCommand none

#AuthorizedKeysCommandUser nobody

# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts

#RhostsRSAAuthentication no

# similar for protocol version 2

#HostbasedAuthentication no

# Change to yes if you don't trust ~/.ssh/known_hosts for

# RhostsRSAAuthentication and HostbasedAuthentication

#IgnoreUserKnownHosts no

# Don't read the user's ~/.rhosts and ~/.shosts files

#IgnoreRhosts yes

# To disable tunneled clear text passwords, change to no here!

#PasswordAuthentication yes

#PermitEmptyPasswords no

PasswordAuthentication yes

# Change to no to disable s/key passwords

#ChallengeResponseAuthentication yes

ChallengeResponseAuthentication no

# Kerberos options

#KerberosAuthentication no

#KerberosOrLocalPasswd yes

#KerberosTicketCleanup yes

#KerberosGetAFSToken no

#KerberosUseKuserok yes

# GSSAPI options

GSSAPIAuthentication yes

GSSAPICleanupCredentials no

#GSSAPIStrictAcceptorCheck yes

#GSSAPIKeyExchange no

#GSSAPIEnablek5users no

# Set this to 'yes' to enable PAM authentication, account processing,

# and session processing. If this is enabled, PAM authentication will

# be allowed through the ChallengeResponseAuthentication and

# PasswordAuthentication. Depending on your PAM configuration,

# PAM authentication via ChallengeResponseAuthentication may bypass

# the setting of "PermitRootLogin without-password".

# If you just want the PAM account and session checks to run without

# PAM authentication, then enable this but set PasswordAuthentication

# and ChallengeResponseAuthentication to 'no'.

# WARNING: 'UsePAM no' is not supported in Red Hat Enterprise Linux and may caus

e several

# problems.

UsePAM yes

#AllowAgentForwarding yes

#AllowTcpForwarding yes

#GatewayPorts no

X11Forwarding yes

X11DisplayOffset 10

X11UseLocalhost yes

#PermitTTY yes

#PrintMotd yes

#PrintLastLog yes

#TCPKeepAlive yes

#UseLogin no

UsePrivilegeSeparation sandbox# Default for new installations.

#PermitUserEnvironment no

#Compression delayed

#ClientAliveInterval 0

#ClientAliveCountMax 3

#ShowPatchLevel no

#UseDNS yes

#PidFile /var/run/sshd.pid

#MaxStartups 10:30:100

#PermitTunnel no

#ChrootDirectory none

#VersionAddendum none

# no default banner path

#Banner none

# Accept locale-related environment variables

AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES

AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT

AcceptEnv LC_IDENTIFICATION LC_ALL LANGUAGE

AcceptEnv XMODIFIERS

# override default of no subsystems

Subsystem sftp /usr/libexec/openssh/sftp-server

# Example of overriding settings on a per-user basis

#Match User anoncvs

# X11Forwarding no

# AllowTcpForwarding no

# PermitTTY no

# ForceCommand cvs server

Thanks for providing that information.


I still haven't been able to reproduce the issue in our environment: our sshd_configs are the same, and I'm using PuTTY to establish the ssh session with X11 forwarding enabled.


I'm wondering if Java 8 is responsible for this behavior. If possible, can you temporarily install Java 9, make it the default version of Java, restart the ScreenConnect client, and check if you still get the X11 connection message?


Regards,

Ben

I didn't see Java 9 available at java.com or openjdk, both have 8.121 as the most current version.

Also, I set up PuTTY on a windows computer and didn't see the problem behavior. It looks like it's limited to OS X ssh and XQuartz.

I tested this on OS X 10.10 with XQuartz 2.7.11. I was able to connect to a CentOS 7 server and launch GUI applications without issue while a 6.1.12292 access client was installed and running.


I'm not certain what's causing the anomalous behavior in your case, but it seems to be something unique to your environment and not directly related to the client.


Even so, if you would like to schedule a troubleshooting session to review the client's behavior in your environment, please email extension@screenconnect.com and refer to this thread.


Cheers,

Ben

Ran into the same exact issue with RHEL 6 Desktop, as soon as I removed CW Control it stopped spitting out those errors every 5 seconds.


Limited to OS X SSH and Linux gnome-terminal SSH, this doesn't happen in Putty. Java version is jre1.8.0_131 which is pretty recent.


There was no trace of these errors in the ~/.xsession-errors file or any file in /var/log so I expect the CW control agent is not playing well with any current X11 displays. Even when X11 forwarding was not enabled via ssh the errors would still occur. I think this is in part due to the default java startup option:

java -XX:+DisplayVMOutputToStderr


This JVM output shouldn't be sent to Stderr as all users see them via terminal and need to go directly to file or the management console.


Please improve upon the linux agent as we now have to find a new monitoring solution for that client.