Hi,
some time ago I have successfully set up the x2goclient 4.1.0.0 for Windows to access some Linux machines via an ssh security gateway. It worked fine. Yesterday I wanted to use that connection with x2gclient 4.1.2.0 and it failed. Today I have tracked this down a bit more and can report this information:
- it works with 4.1.0.0
- it stops working with 4.1.1.1 or newer
- the session configuration looks like this:
- Server:
- Host: destination host behind the gateway
- Use proxy server for ssh connection
- Proxy:
- Proxy type: ssh
- Proxy host: gateway
- Proxy port: 22
- use same user as for x2go server
- Server:
- The connection interactively asks for the password of the gateway and fails directly after entering it.
The gateway is setup like this:
- ssh <user>@gateway
- run one of two valid commands. Any other command will immediately abort the connection to the gateway. The main allowed command is ssh to a number of defined hosts. The other command is irrelevant here.
Here's some log: (invalid command)
$ ssh user@gateway Password: [entering my secure password from password generator] Last login: Thu May 16 15:30:02 2019 from [CENSORED] Enter command: echo test Connection to gateway closed.
Here's some log: (valid command)
$ ssh user@gateway Password: [entering my secure password from password generator] Last login: Thu May 16 16:08:59 2019 from [CENSORED] Enter command: ssh desthost key_from_blob: remaining bytes in key blob 36 ssh-keysign not enabled in /usr/pkg/etc/ssh/ssh_config ssh_keysign: no reply key_sign failed Last login: Tue Apr 30 16:37:30 2019 from CENSORED [Prompt on desthost] $
Working debug log (4.1.0.0):
x2go-DEBUG-../src/onmainwindow.cpp:2860> Starting new ssh connection to server:"desthost":"22" krbLogin: false x2go-DEBUG-../src/sshmasterconnection.cpp:175> SshMasterConnection, host "desthost"port 22user "username"useproxy trueproxyserver "gateway"proxyport 22 x2go-DEBUG-../src/sshmasterconnection.cpp:212> Starting SSH connection without Kerberos authentication. x2go-DEBUG-../src/sshmasterconnection.cpp:216> SshMasterConnection, instance SshMasterConnection(0x318fb40) created. x2go-DEBUG-../src/sshmasterconnection.cpp:452> SshMasterConnection, instance SshMasterConnection(0x318fb40) entering thread. x2go-DEBUG-../src/sshmasterconnection.cpp:456> proxyserver: "gateway"proxyport: 22proxylogin: "username" x2go-DEBUG-../src/sshmasterconnection.cpp:175> SshMasterConnection, host "gateway"port 22user "username"useproxy falseproxyserver ""proxyport 0 x2go-DEBUG-../src/sshmasterconnection.cpp:212> Starting SSH connection without Kerberos authentication. x2go-DEBUG-../src/sshmasterconnection.cpp:216> SshMasterConnection, instance SshMasterConnection(0x318fbf8) created. x2go-DEBUG-../src/sshmasterconnection.cpp:452> SshMasterConnection, instance SshMasterConnection(0x318fbf8) entering thread. x2go-DEBUG-../src/sshmasterconnection.cpp:488> libssh not initialized yet. Initializing. x2go-DEBUG-../src/sshmasterconnection.cpp:532> Setting SSH directory to "C:/Users/xxx/ssh" x2go-DEBUG-../src/sshmasterconnection.cpp:799> cserverAuth x2go-DEBUG-../src/sshmasterconnection.cpp:814> state: 1
x2go-DEBUG-../src/sshmasterconnection.cpp:650> Setting SSH directory to "C:/Users/xxx/ssh" x2go-DEBUG-../src/sshmasterconnection.cpp:989> Challenge authentication requested.
x2go-DEBUG-../src/sshmasterconnection.cpp:867> Have prompts: 1
x2go-DEBUG-../src/sshmasterconnection.cpp:873> Prompt[0]: |Password: |
x2go-DEBUG-../src/sshmasterconnection.cpp:879> Password request
x2go-DEBUG-../src/sshmasterconnection.cpp:867> Have prompts: 0
x2go-DEBUG-../src/sshmasterconnection.cpp:950> Challenge authentication OK.
x2go-DEBUG-../src/sshmasterconnection.cpp:664> User authentication OK. x2go-DEBUG-../src/sshmasterconnection.cpp:224> SSH proxy connected.
Non-working debug log (4.1.1.1):
x2go-DEBUG-../src/sshmasterconnection.cpp:175> SshMasterConnection, host "desthost"; port 22; user "username"; useproxy true; proxyserver "gateway"; proxyport 22 x2go-DEBUG-../src/sshmasterconnection.cpp:248> Starting SSH connection without Kerberos authentication. x2go-DEBUG-../src/sshmasterconnection.cpp:252> SshMasterConnection, instance SshMasterConnection(0x35aed70) created. x2go-DEBUG-../src/sshmasterconnection.cpp:520> SshMasterConnection, instance SshMasterConnection(0x35aed70) entering thread. x2go-DEBUG-../src/sshmasterconnection.cpp:524> proxyserver: "gateway"; proxyport: 22; proxylogin: "username" x2go-DEBUG-../src/sshmasterconnection.cpp:175> SshMasterConnection, host "gateway"; port 22; user "username"; useproxy false; proxyserver ""; proxyport 0 x2go-DEBUG-../src/sshmasterconnection.cpp:248> Starting SSH connection without Kerberos authentication. x2go-DEBUG-../src/sshmasterconnection.cpp:252> SshMasterConnection, instance SshMasterConnection(0x3543230) created. x2go-DEBUG-../src/sshmasterconnection.cpp:520> SshMasterConnection, instance SshMasterConnection(0x3543230) entering thread. x2go-DEBUG-../src/sshmasterconnection.cpp:592> Setting SSH directory to C:/Users/xxx/ssh x2go-DEBUG-../src/sshmasterconnection.cpp:840> Session port before config file parse: 22 x2go-DEBUG-../src/sshmasterconnection.cpp:850> Session port after config file parse: 22 x2go-DEBUG-../src/sshmasterconnection.cpp:915> Session port before config file parse (part 2): 22 x2go-DEBUG-../src/sshmasterconnection.cpp:925> Session port after config file parse (part 2): 22 x2go-DEBUG-../src/sshmasterconnection.cpp:950> cserverAuth x2go-DEBUG-../src/sshmasterconnection.cpp:991> state: 1
x2go-DEBUG-../src/sshmasterconnection.cpp:711> Setting SSH directory to C:/Users/xxx/ssh x2go-DEBUG-../src/sshmasterconnection.cpp:1263> Challenge authentication requested.
x2go-DEBUG-../src/sshmasterconnection.cpp:1132> Have prompts: 1
x2go-DEBUG-../src/sshmasterconnection.cpp:1138> Prompt[0]: |Password: |
x2go-DEBUG-../src/sshmasterconnection.cpp:1144> Password request
x2go-DEBUG-../src/sshmasterconnection.cpp:1132> Have prompts: 0
x2go-DEBUG-../src/sshmasterconnection.cpp:1226> Challenge authentication OK.
x2go-DEBUG-../src/sshmasterconnection.cpp:726> User authentication OK. x2go-DEBUG-../src/sshmasterconnection.cpp:740> Login Check - Failed x2go-DEBUG-../src/sshmasterconnection.cpp:459> SSH proxy interaction finished x2go-DEBUG-../src/sshmasterconnection.cpp:802> SshMasterConnection, instance SshMasterConnection(0x35aed70) waiting for thread to finish. x2go-DEBUG-../src/sshmasterconnection.cpp:806> SshMasterConnection, instance SshMasterConnection(0x35aed70) thread finished. x2go-DEBUG-../src/sshmasterconnection.cpp:813> SshMasterConnection, instance SshMasterConnection(0x35aed70) finished destructor.
In the non-working case we see "Login Check - Failed", the rest of the log looks the same. I think that login check is issuing a command on the proxy to check if the proxy is working ("echo LOGIN OK"). And due to the nature of our gateway (see above) this fails, because it is an invalid command.
Unfortunately I don't really see if this assumption is correct because I have no access to the gateway logs and the x2goclient logs do not contain any information _why_ the login check failed. I have tried getting some gateway logs but I have not yet gotten anything.
Is there anything I can do to bypass that login check?
Uli
log looks the same. I think that login check is issuing a command on the proxy to check if the proxy is working ("echo LOGIN OK"). And due to the nature of our gateway (see above) this fails, because it is an invalid command.
Unfortunately I don't really see if this assumption is correct because I have no access to the gateway logs and the x2goclient logs do not contain any information _why_ the login check failed. I have tried getting some gateway logs but I have not yet gotten anything.
Is there anything I can do to bypass that login check?
I have now done some tests:
- this also happens with the x2goclient 4.1.2.2 on Linux
- I can confirm that my assumption about the LOGIN OK check was correct. Inserting "return true;" just before the line " if ( ssh_channel_request_exec ( channel, "echo \"LOGIN OK\"" ) != SSH_OK ) " in sshmasterconnection.cpp and thus skipping the whole interactivity code makes it work again.
This check was introduced as a result of Bug #592 to enable the user changing an expired password interactively but I have not fully understood the whole idea of sending echo "LOGIN OK" and then checking if is NOT in the buffer. Isn't checking for pty sufficient?
QString inf=QByteArray ( buffer,nbytes );
x2goDebug<<"LOGIN CHECK:"<<inf;
if(inf.indexOf("LOGIN OK")!=-1)
{
x2goDebug<<"don't have interaction";
hasInterraction=false;
break;
}@Alex can you please explain?
Uli
Hello Uli,
It's not only about updating the user passwords. This kind interaction could be used for 2-factor authentication and in many other cases. There are many possible cases when server needs to have some additional interaction with user and updating of passwords is only one of them. After user auth is important to figure out if our session is ready and accepting user commands or we need further interaction. I didn't find better solution to find this out than sending an echo command and parse the answer. It's sad, that it's breaking your setup. If I understand it right, it's because your proxy closing connection when user executing something else than ssh. Maybe you can reconfigure your proxy and make "echo LOGIN OK" a valid command, this should solve your problem.
regards Alex
Am 16.05.19 um 16:49 schrieb Ulrich Sibiller:
log looks the same. I think that login check is issuing a command on the proxy to check if the proxy is working ("echo LOGIN OK"). And due to the nature of our gateway (see above) this fails, because it is an invalid command.
Unfortunately I don't really see if this assumption is correct because I have no access to the gateway logs and the x2goclient logs do not contain any information _why_ the login check failed. I have tried getting some gateway logs but I have not yet gotten anything.
Is there anything I can do to bypass that login check?
I have now done some tests:
- this also happens with the x2goclient 4.1.2.2 on Linux
- I can confirm that my assumption about the LOGIN OK check was correct. Inserting "return true;" just before the line " if ( ssh_channel_request_exec ( channel, "echo \"LOGIN OK\"" ) != SSH_OK ) " in sshmasterconnection.cpp and thus skipping the whole interactivity code makes it work again.
This check was introduced as a result of Bug #592 to enable the user changing an expired password interactively but I have not fully understood the whole idea of sending echo "LOGIN OK" and then checking if is NOT in the buffer. Isn't checking for pty sufficient?
QString inf=QByteArray ( buffer,nbytes ); x2goDebug<<"LOGIN CHECK:"<<inf; if(inf.indexOf("LOGIN OK")!=-1) { x2goDebug<<"don't have interaction"; hasInterraction=false; break; }@Alex can you please explain?
Uli
--
Oleksandr Shneyder | Email: o.shneyder@phoca-gmbh.de phoca GmbH | Tel. : 0911 - 14870374 0 Schleiermacherstr. 2 | Fax. : 0911 - 14870374 9 D-90491 Nürnberg | Mobil: 0163 - 49 64 461
Geschäftsführung: Dipl.-Inf. Oleksandr Shneyder
Amtsgericht München | http://www.phoca-gmbh.de HRB 196 658 | http://www.x2go.org USt-IdNr.: DE281977973
On Fri, May 17, 2019 at 3:48 PM Oleksandr Shneyder <o.shneyder@phoca-gmbh.de> wrote:
It's not only about updating the user passwords. This kind interaction could be used for 2-factor authentication and in many other cases. There are many possible cases when server needs to have some additional interaction with user and updating of passwords is only one of them. After user auth is important to figure out if our session is ready and accepting user commands or we need further interaction. I didn't find better solution to find this out than sending an echo command and parse the answer. It's sad, that it's breaking your setup. If I understand it right, it's because your proxy closing connection when user executing something else than ssh. Maybe you can reconfigure your proxy and make "echo LOGIN OK" a valid command, this should solve your problem.
Thanks for clarification.
No, I have no control over that proxy. This is a security gateway to a big company. I suggest a checkmark indication if that check should be skipped.
Uli
Am 17.05.19 um 08:55 schrieb Ulrich Sibiller:
On Fri, May 17, 2019 at 3:48 PM Oleksandr Shneyder <o.shneyder@phoca-gmbh.de> wrote:
It's not only about updating the user passwords. This kind interaction could be used for 2-factor authentication and in many other cases. There are many possible cases when server needs to have some additional interaction with user and updating of passwords is only one of them. After user auth is important to figure out if our session is ready and accepting user commands or we need further interaction. I didn't find better solution to find this out than sending an echo command and parse the answer. It's sad, that it's breaking your setup. If I understand it right, it's because your proxy closing connection when user executing something else than ssh. Maybe you can reconfigure your proxy and make "echo LOGIN OK" a valid command, this should solve your problem.
Thanks for clarification.
No, I have no control over that proxy. This is a security gateway to a big company. I suggest a checkmark indication if that check should be skipped.
Uli
Hi Uli,
technically it's a very simple solution. However I'm not sure if it worth to make UI more complicated and loaded with features which are required only by one untypical setup. On this place I would like to ask the list members if some one has a same usecase or would find this feature useful.
Regards Alex
--
Oleksandr Shneyder | Email: o.shneyder@phoca-gmbh.de phoca GmbH | Tel. : 0911 - 14870374 0 Schleiermacherstr. 2 | Fax. : 0911 - 14870374 9 D-90491 Nürnberg | Mobil: 0163 - 49 64 461
Geschäftsführung: Dipl.-Inf. Oleksandr Shneyder
Amtsgericht München | http://www.phoca-gmbh.de HRB 196 658 | http://www.x2go.org USt-IdNr.: DE281977973
Am 17.05.19 um 16:39 schrieb Oleksandr Shneyder:
technically it's a very simple solution. However I'm not sure if it worth to make UI more complicated and loaded with features which are required only by one untypical setup. On this place I would like to ask the list members if some one has a same usecase or would find this feature useful.
How about not adding an UI item but merely a config file option?
-Stefan
-- 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
would be OK for me, but it'll require more user experience for the client configuration. For Windows users even more, they'll need to edit windows registry.
Am 17.05.19 um 09:44 schrieb Stefan Baur:
Am 17.05.19 um 16:39 schrieb Oleksandr Shneyder:
technically it's a very simple solution. However I'm not sure if it worth to make UI more complicated and loaded with features which are required only by one untypical setup. On this place I would like to ask the list members if some one has a same usecase or would find this feature useful.
How about not adding an UI item but merely a config file option?
-Stefan
x2go-dev mailing list x2go-dev@lists.x2go.org https://lists.x2go.org/listinfo/x2go-dev
--
Oleksandr Shneyder | Email: o.shneyder@phoca-gmbh.de phoca GmbH | Tel. : 0911 - 14870374 0 Schleiermacherstr. 2 | Fax. : 0911 - 14870374 9 D-90491 Nürnberg | Mobil: 0163 - 49 64 461
Geschäftsführung: Dipl.-Inf. Oleksandr Shneyder
Amtsgericht München | http://www.phoca-gmbh.de HRB 196 658 | http://www.x2go.org USt-IdNr.: DE281977973
On Fri, May 17, 2019 at 5:06 PM Oleksandr Shneyder <o.shneyder@phoca-gmbh.de> wrote:
technically it's a very simple solution. However I'm not sure if it worth to make UI more complicated and loaded with features which are required only by one untypical setup.
One thing here is that it used to work and stopped beginning with 4.1.1.1. So the correct solution would have been to leave the old default and add an UI option that enables the new behaviour. But as noone has complained the past year we can safely assume that noone is having problems with the new behaviour.
On this place I would like to ask the list members if some one has a same usecase or would find this feature useful.
How about not adding an UI item but merely a config file option?
would be OK for me, but it'll require more user experience for the client configuration. For Windows users even more, they'll need to edit windows registry.
Yeah, but as I am the first one to notice this chances are noone else will ever need this... So having to configure that in a cumbersome way might be ok.
Alternatively we could add a hack: if the proxy hostname has some special form, e.g. "!hostname", that very check will be skipped. As proxy and normal hosts are both controlled via the same code in SshmasterConnection this way the user could configure that for both connections independently.
Third option was to add a command line option that simply deactivates the check. This would account for all session and for proxy and non-prpoxy session, but again: not mayn people will ever need this.
Fourth option was to make the command (and its expected result) that is used to check for interactivity ("echo "LOGIN OK"") configurable. An empty value will then skip the check.
Alex, are you aware of setup that require the LOGIN OK check? Do you have access to such a system? Maybe we can find another indicator that makes the check obsolete.
Uli
On Fri, May 17, 2019 at 9:31 PM Ulrich Sibiller <ulrich.sibiller@gmail.com> wrote:
Alternatively we could add a hack: if the proxy hostname has some special form, e.g. "!hostname", that very check will be skipped. As proxy and normal hosts are both controlled via the same code in SshmasterConnection this way the user could configure that for both connections independently.
I have just implemented that, see attached patch 0001. It makes my setup work. What do you think of this approach?
While doing that I also noticed that checkLogin() is missing some cleanup code, see attached patch 0002.
Uli
Hi Uli,
I could leave with this "hack". I think we can take your patches in the x2go client source.
regards, Alex
Am 17.05.19 um 15:51 schrieb Ulrich Sibiller:
On Fri, May 17, 2019 at 9:31 PM Ulrich Sibiller <ulrich.sibiller@gmail.com> wrote:
Alternatively we could add a hack: if the proxy hostname has some special form, e.g. "!hostname", that very check will be skipped. As proxy and normal hosts are both controlled via the same code in SshmasterConnection this way the user could configure that for both connections independently.
I have just implemented that, see attached patch 0001. It makes my setup work. What do you think of this approach?
While doing that I also noticed that checkLogin() is missing some cleanup code, see attached patch 0002.
Uli
--
Oleksandr Shneyder | Email: o.shneyder@phoca-gmbh.de phoca GmbH | Tel. : 0911 - 14870374 0 Schleiermacherstr. 2 | Fax. : 0911 - 14870374 9 D-90491 Nürnberg | Mobil: 0163 - 49 64 461
Geschäftsführung: Dipl.-Inf. Oleksandr Shneyder
Amtsgericht München | http://www.phoca-gmbh.de HRB 196 658 | http://www.x2go.org USt-IdNr.: DE281977973
- On 5/17/19 10:51 PM, Ulrich Sibiller wrote:
On Fri, May 17, 2019 at 9:31 PM Ulrich Sibiller <ulrich.sibiller@gmail.com> wrote:
Alternatively we could add a hack: if the proxy hostname has some special form, e.g. "!hostname", that very check will be skipped. As proxy and normal hosts are both controlled via the same code in SshmasterConnection this way the user could configure that for both connections independently.
I have just implemented that, see attached patch 0001. It makes my setup work. What do you think of this approach?
Originally, I thought that this would conflict with ssh_config support (because such host names need not be valid DNS names), but I guess it's fine, since the characters *, ?, "," and ! are special in this context and used for pattern matching, so they cannot be used in such host names directly. Since ! is part of that set, I guess we're free to use it for such a purpose.
Applied.
While doing that I also noticed that checkLogin() is missing some cleanup code, see attached patch 0002.
Applied that one, too.
Mihai
-
Mihai Moldovan -
Oleksandr Shneyder -
Stefan Baur -
Ulrich Sibiller -
Ulrich Sibiller