Hello, all. We recently recreated an X2Go Server and found we had serious ssh key issues when we tried to connect from the previously existing X2Go clients. We're still working these through so I'll list them in the order we find them.
The GUI key popping up Accept Key dialogs with Yes and No options but no text. It was only when we canceled that we saw the error message about there being an old, conflicting key. By the way, we use both hashed known_host files and non-default ssh ports. This created a problem when we went to remove the offending keys in that the syntax ssh-keygen -R <server name> did not work. We needed to use ssh-keygen -R [<server name>]:<port number> (note the brackets).
We then hit a problem where the X2Go Client for some reason started trying to open an SSH sessions as root. Since we use active host intrusion detection (OSSEC), the failed login attempts lock out the user and the screen stops at the X2Go logo. Oops! This was our misunderstanding of the auth.log. The problem was that our users are only defined in LDAP. We configured pam to look at pam_unix first. This tripped our HIDS and blocked our users. From our internal documentation:
Now we need to fix some pam files. It is critical that the ldap modules are processed first even though that is non-standard. In the X2Go environment, many ssh sessions are fired off in quick succession. Since the pam_unix authentications fail for the LDAP users (as they are not defined locally), all the failed authentications trip the OSSEC auto-response and block the user from access to VD01. Thus, LDAP credentials MUST be processed first.
This just leaves the empty dialog box. Thanks - John