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
On Sun, 2010-03-14 at 04:18 -0400, John A. Sullivan III wrote:
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 <snip> Oops! We've hit some nastier issues. Using an X2Go Client on a different station this morning, I encountered the empty dialog. I cleared the offending entry from known_hosts and tried again. This time I was told I needed to answer yes or no. Clicking Yes had no effect. Clicking no caused the entire x2goclient to crash and disappear - I assume a seg fault.
I had a sneaking suspicion of what was happening. Connecting from a console gave me this: Warning: the RSA host key for '[vdhost01.ssiservices.biz]:443' differs from the key for the IP address '[208.46.93.8]:443' Offending key for IP in /home/jsullivan/.ssh/known_hosts:3 Matching host key in /home/jsullivan/.ssh/known_hosts:24 Are you sure you want to continue connecting (yes/no)?
I cleared the offending IP address entry and all worked well but we do have this seg fault to address - John
John A. Sullivan III <jsullivan@...> writes:
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).
I've seen one of the symptoms you describe:
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.
I used vi to remove the entry in my hosts file. But that blank pop up that just asks: YES NO and nothing else ?? Selecting YES didn't seem to do anything. NO at least popped up an error message in another window.
John A. Sullivan III <jsullivan@...> writes:
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).
I've seen one of the symptoms you describe:
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.
I used vi to remove the entry in my hosts file. But that blank pop up that just asks: YES NO and nothing else ?? Selecting YES didn't seem to do anything. NO at least popped up an error message in another window. <snip> You may have a second conflict. There are sometimes entries for both
On Thu, 2010-03-25 at 19:51 +0000, brian mullan wrote: the host by name and IP address. One needs to remove both to avoid any error messages (perhaps X2Go is only capturing stdout and these messages are written to stderr - just a guess - I've yet to look at the code). You can probably tell by opening a command line ssh session and seeing what message it gives you.
Let's say we have x2gohost.me.com at 1.2.3.4. one would need to do ssh-keygen -R x2gohost.me.com ssh-keygen -R 1.2.3.4
If one uses non-standard ssh ports (an excellent security idea), then the names must be in brackets with the port, e.g., ssh-keygen -R [x2gohost.me.com]:222 ssh-keygen -R [1.2.3.4]:222
At least, that's how it was for us. Hope this helps - John
-
brian mullan -
John A. Sullivan III