Package: x2goclient Version: 4.1.2.2
Hello, devs!
I'm afraid this is not a very precise bug report. Any assistance in how to investigate this is appreciated.
We're running x2goclient 4.1.2.2 on Windows-10 machines, this has served us well up to now. With our new RedHat Enterprise Server 8.4 in production, we see the client crashing very often.
When the client crashes, it does so shortly after trying to log in to a new or existing session. The clients "show details" window pane is activated, but the client dies before anything can be seen there.
On the server, just these entries in the system logs appears:
Aug 05 14:42:56 mimi.uio.no sshd[2421324]: Connection from 2001:700:100:4028:9462:e3c7:21c5:ec1c port 49763 on 2001:700:100:118::101 port 22 Aug 05 14:42:59 mimi.uio.no sshd[2421324]: Connection reset by 2001:700:100:4028:9462:e3c7:21c5:ec1c port 49763 [preauth]
If I disable IPv6:
Aug 05 14:45:30 mimi.uio.no sshd[2421601]: Connection from 193.157.161.44 port 57619 on 129.240.118.101 port 22 Aug 05 14:45:33 mimi.uio.no sshd[2421601]: Connection reset by 193.157.161.44 port 57619 [preauth]
Note the absence of the "Fail password for ..." log entry. It looks like it never gets to even try authenticating.
There is no problem logging in with putty from the same client machine, both with IPv6 and IPv4. Neither have I had this problem (at least not so frequent) with the Linux client.
The server is running sshd and x2goserver from the RHEL8/EPEL repos, packages openssh-server-8.0p1-6 and x2goserver-4.1.0.3-9, respectively.
I eventually tried to run sshd -ddd on the server and catch the output.
The typescripts are attached (slightly edited): one where the client crashed;
and one where it didn't (but couldn't authenticate, bad password). I'm no
expert on ssh, but it seems like the difference appears after the key exchange
("KEX done"), when the instance that crashed never reaches the bit with
userauth-request.
I also tried "setenforce 0" on the server, i.e. disable SELinux, but the client still crashed.
As it is, I can't clearly provide a procedure to reproduce the problem, as it doesn't always happen.
If more information is required, or there are suggested steps to take, please let me know.
Thanks in advance, and best regards,
Hans Peter Verne -- IT-drift Geofag.
In 1934, Van der Lubbe was beheaded in a German prison yard. In 1967, a court in West Berlin overturned the 1933 verdict, and posthumously changed Van der Lubbe's sentence to eight years in prison. -- "Reichstag fire" on Wikipedia.
Hans, I wonder if this is the same issue that is described in bug report #1520 ( https://bugs.x2go.org/cgi-bin/bugreport.cgi?bug=1520). Can you try the workaround from that bug report?
Thanks, Adam
On Wed, Aug 25, 2021 at 6:03 AM Hans Peter Verne <h.p.verne@geo.uio.no> wrote:
Package: x2goclient Version: 4.1.2.2
Hello, devs!
I'm afraid this is not a very precise bug report. Any assistance in how to investigate this is appreciated.
We're running x2goclient 4.1.2.2 on Windows-10 machines, this has served us well up to now. With our new RedHat Enterprise Server 8.4 in production, we see the client crashing very often.
When the client crashes, it does so shortly after trying to log in to a new or existing session. The clients "show details" window pane is activated, but the client dies before anything can be seen there.
On the server, just these entries in the system logs appears:
Aug 05 14:42:56 mimi.uio.no sshd[2421324]: Connection from 2001:700:100:4028:9462:e3c7:21c5:ec1c port 49763 on 2001:700:100:118::101 port 22 Aug 05 14:42:59 mimi.uio.no sshd[2421324]: Connection reset by 2001:700:100:4028:9462:e3c7:21c5:ec1c port 49763 [preauth]
If I disable IPv6:
Aug 05 14:45:30 mimi.uio.no sshd[2421601]: Connection from 193.157.161.44 port 57619 on 129.240.118.101 port 22 Aug 05 14:45:33 mimi.uio.no sshd[2421601]: Connection reset by 193.157.161.44 port 57619 [preauth]
Note the absence of the "Fail password for ..." log entry. It looks like it never gets to even try authenticating.
There is no problem logging in with putty from the same client machine, both with IPv6 and IPv4. Neither have I had this problem (at least not so frequent) with the Linux client.
The server is running sshd and x2goserver from the RHEL8/EPEL repos, packages openssh-server-8.0p1-6 and x2goserver-4.1.0.3-9, respectively.
I eventually tried to run sshd -ddd on the server and catch the output. The typescripts are attached (slightly edited): one where the client crashed; and one where it didn't (but couldn't authenticate, bad password). I'm no expert on ssh, but it seems like the difference appears after the key exchange ("KEX done"), when the instance that crashed never reaches the bit with userauth-request.
I also tried "setenforce 0" on the server, i.e. disable SELinux, but the client still crashed.
As it is, I can't clearly provide a procedure to reproduce the problem, as it doesn't always happen.
If more information is required, or there are suggested steps to take, please let me know.
Thanks in advance, and best regards,
Hans Peter Verne -- IT-drift Geofag.
In 1934, Van der Lubbe was beheaded in a German prison yard. In 1967, a court in West Berlin overturned the 1933 verdict, and posthumously changed Van der Lubbe's sentence to eight years in prison. -- "Reichstag fire" on Wikipedia.
x2go-dev mailing list x2go-dev@lists.x2go.org https://lists.x2go.org/listinfo/x2go-dev
-- Adam Dorsey NOAA RDHPCS Systems Administrator Site Lead CSRA / RedLine Performance Solutions, LLC
NOAA NESCC 1000 Galliher Drive, Suite 333, Fairmont, WV 26554 office: (304) 367-2882 cell: (304) 685-9345 adam.dorsey@noaa.gov
On 25.08.2021 15:19, Adam Dorsey - NOAA Affiliate wrote:
Hans, I wonder if this is the same issue that is described in bug report #1520 (https://bugs.x2go.org/cgi-bin/bugreport.cgi?bug=1520 Can you try the workaround from that bug report?
Thank you for the feedback.
I assume the workaround would be to remove aes128-ctr from the "Ciphers" line in /etc/ssh/sshd_config
I can do that for test purpose, but it will be reset by automatic routines (CFengine) maintained by central IT, so it will be a bit more work (and I would need some arguments) to get it permanently changed.
This is, however, a smoking gun. The comment in the file says the cipher selections was revised 2021-06-22.
But when me and my coworkers test the x2go client now, it works
perfectly every time! On the same w-10 machines, with the same
server, same session config. And no changes to sshd_config.
Thus, testing without aes128-ctr would not tell me much.
Unless this is just coincidental (it didn't always crash, anyway), the only change I can imagine is some Windows update since I struggled with this 3 weeks ago.
Also, I noted that x2go complained about the host key being changed (it hasn't), with the usual warning about MITM attack (pretty sure there isn't one). So maybe some bug was fixed in a Windows library routine used for key handling? I'm throwing things at the wall here!
Bottom line, we can probably let this problem lie for now. I still wish for a way to catch diagnostics from the x2go client, also after the status pane has closed.
Regards,
Hans Peter Verne -- IT-drift Geofag.
In 1934, Van der Lubbe was beheaded in a German prison yard. In 1967, a court in West Berlin overturned the 1933 verdict, and posthumously changed Van der Lubbe's sentence to eight years in prison. -- "Reichstag fire" on Wikipedia.
Am 27.08.21 um 12:26 schrieb Hans Peter Verne:
I still wish for a way to catch diagnostics from the x2go client, also after
For that, you need to select the debug version of X2GoClient when installing X2GoClient for Windows. MacOS and Linux versions of X2GoClient support this out of the box.
With the debug version installed, you can run
"x2goclient.debug.exe --debug" and redirect the output to a file (be sure to redirect both STDOUT and STDERR).
Kind Regards, Stefan Baur
-- BAUR-ITCS UG (haftungsbeschränkt) Geschäftsführer: Stefan Baur Eichenäckerweg 10, 89081 Ulm | Registergericht Ulm, HRB 724364 Fon/Fax 0731 40 34 66-36/-35 | USt-IdNr.: DE268653243
On 27.08.2021 12:32, Stefan Baur wrote:
Am 27.08.21 um 12:26 schrieb Hans Peter Verne:
I still wish for a way to catch diagnostics from the x2go client, also after
For that, you need to select the debug version of X2GoClient when installing X2GoClient for Windows. MacOS and Linux versions of X2GoClient support this out of the box.
With the debug version installed, you can run
"x2goclient.debug.exe --debug" and redirect the output to a file (be sure to redirect both STDOUT and STDERR).
Thanks -- very useful!
Regards,
Hans Peter Verne -- IT-drift Geofag.
In 1934, Van der Lubbe was beheaded in a German prison yard. In 1967, a court in West Berlin overturned the 1933 verdict, and posthumously changed Van der Lubbe's sentence to eight years in prison. -- "Reichstag fire" on Wikipedia.
-
Adam Dorsey - NOAA Affiliate -
Hans Peter Verne -
Stefan Baur