Hi,
On 13.03.2015 02:48 PM, swizz ly wrote:
[...] In case of the x2goclient-cli Perl script, that comes with the x2goclient source, I found, that for a single x2go connection several (3-4x?) SSH connections are made in the background. In case of SecurID RSA, only the first SSH connection can work with a given PASSCODE, it is accepted only at the first SSH connection. Perhaps the normal x2goclient behaves the same way: it tries to connect using the same PASSCODE several times, and this could be the cause of the problem.
Well, the answer is a little bit complicated.
Yes, it behaves exactly the same way. Several programs are started server side.
This includes session discovery and of course starting a new session or resuming it.
For that, a new connection is established via libssh. This connection is authenticated by any means provided: password, key, or keyboard-interactive (i.e., SecurID.)
This said, libssh uses channels for spawning new commands/shells. These channels do NO authentication but use the established main connection.
X2Go Client should only open up one connection and then use multiple channels over the already authenticated connection for doing its work.
Is it really not and instead opening up multiple connections?
Mihai
I can't speak to the RSA pam plugin, but I know that X2Go works with OTPs using pam-radius. You can see this: http://wiki.x2go.org/doku.php/doc:deployment-stories:wikid.
(Better to use the standard protocol for easier switching too.)
HTH,
Nick
On Fri, Mar 13, 2015 at 12:12 PM, Mihai Moldovan <ionic@ionic.de> wrote:
Hi,
On 13.03.2015 02:48 PM, swizz ly wrote:
[...] In case of the x2goclient-cli Perl script, that comes with the x2goclient source, I found, that for a single x2go connection several (3-4x?) SSH connections are made in the background. In case of SecurID RSA, only the first SSH connection can work with a given PASSCODE, it is accepted only at the first SSH connection. Perhaps the normal x2goclient behaves the same way: it tries to connect using the same PASSCODE several times, and this could be the cause of the problem.
Well, the answer is a little bit complicated.
Yes, it behaves exactly the same way. Several programs are started server side.
This includes session discovery and of course starting a new session or resuming it.
For that, a new connection is established via libssh. This connection is authenticated by any means provided: password, key, or keyboard-interactive (i.e., SecurID.)
This said, libssh uses channels for spawning new commands/shells. These channels do NO authentication but use the established main connection.
X2Go Client should only open up one connection and then use multiple channels over the already authenticated connection for doing its work.
Is it really not and instead opening up multiple connections?
Mihai
x2go-user mailing list x2go-user@lists.x2go.org http://lists.x2go.org/listinfo/x2go-user
-- Nick Owen -- WiKID Systems, Inc. http://www.wikidsystems.com Commercial/Open Source Two-Factor Authentication http://twitter.com/wikidsystems | #wikid on freenode.net Get our low-volume newsletter - Notices, updates : http://eepurl.com/zzUeP
On 14.03.2015 10:48 AM, swizz ly wrote:
[...] I get the same results: no messages at the RSA console, if I make a normal SSH connection forcing password authentication: "ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no user@server". Can it be that x2goclient forces the password authentication explicitely if there is no publickey?
Maybe. I have to check. Will do this later.
Shouldn't pam-radius also use password+keyboard-interactive, though? Given that it works for Nick, I'm skeptical when it comes to x2goclient forcing password auth. I may be wrong by assuming pam-radius does uses keyboard-interactive authentication right after password authentication, though.
Mihai
On 16.03.2015 04:53 PM, swizz ly wrote:
I have found the problem. The prompt of the SSH server is coded in the source code of x2goclient. We use for authentication via SecurID a different SSH promtp to emphasize the difference. Last week I already changed the prompt of the SecurID prompt to be the same as the normal SSH, but I didn't notice the blank after the "Password: "... Unfortunately, I haven't managed to get the blank space at the end of "Password: ". So I just edited the source code of the x2goclient, and changed the line where the expected prompt is defined. This solution worked. Would it make sense to include the expected ssh prompt as a parameter in x2go in order to avoid having to recomplie the source code in a such case?
Hum, maybe. I would be a really obscure setting, though. Is there no default other than "Password: "? Adding/hardcoding other defaults is definitely an option. Everybody else who deviates from that is basically on their own -- so a parameter would make sense.
Then again, how much sense does that make as a default parameter? Suppose you have multiple sessions and want to connect to different servers -- which also happen to have different prompts. A global command line parameter would make connecting to one prompt type possible (only.)
This probably should be a per-session preference, if anything. But the use case is so special that I'm unsure whether it makes sense as a general setting in the client or not...
Mihai
Hi
I have same problem! Did you recompiled X2go-client for Windows in other to fix this?
Whats the easy fix for this?
Regards
Perhaps better to use an open standard like RADIUS which allows you to tie in your directory.
See http://wiki.x2go.org/doku.php/doc:deployment-stories:wikid for an example.
hth,
nick
On Thu, Nov 3, 2016 at 6:32 AM, swizz ly <swizz.ly@gmx.ch> wrote:
Hi guys,
Is there any update on this issue? I posted the original mail for more than a year ago. I tried the current X2Go Windows Client V4.0.5.2 but unfortunatelly it is still not working with two-factor SecurID authorisation. It would be very simple to fix this issue, just to remove the fix hard-coded SSH-Prompt from the source code. To whom shall I write to make this change happen?
Here is the simple fix, if someone would be interested:
Edit sshmasterconnection.cpp file and in the function bool SshMasterConnection::userChallengeAuth() we need to change the following line:
if(pr=="Password: ")
to
if(pr=="Password: " or pr=="Enter PASSCODE:")
Instead of "Enter PASSCODE:" you can use whatever prompt the SSH sends you. But it would be much better not to use fix, hard-coded prompt in the code at all.
Regards
Gesendet: Mittwoch, 15. Juni 2016 um 11:52 Uhr Von: ilukeberry <luka.kodric@bitstamp.net> An: x2go-user@lists.x2go.org Betreff: Re: [X2Go-User] X2Go Two-factor-authentication with SecurID Hi
I have same problem! Did you recompiled X2go-client for Windows in other to fix this?
Whats the easy fix for this?
Regards
x2go-user mailing list x2go-user@lists.x2go.org http://lists.x2go.org/listinfo/x2go-user
x2go-user mailing list x2go-user@lists.x2go.org http://lists.x2go.org/listinfo/x2go-user
-- Nick Owen -- WiKID Systems, Inc. http://www.wikidsystems.com On-premises Two-Factor Authentication http://twitter.com/wikidsystems | #wikid on freenode.net Get our low-volume newsletter - Notices, updates : http://eepurl.com/zzUeP
On 03.11.2016 11:32 AM, swizz ly wrote:
Is there any update on this issue? I posted the original mail for more than a year ago. I tried the current X2Go Windows Client V4.0.5.2 but unfortunatelly it is still not working with two-factor SecurID authorisation. It would be very simple to fix this issue, just to remove the fix hard-coded SSH-Prompt from the source code. To whom shall I write to make this change happen?
Sorry for getting back at you so late.
I've added the new prompt to X2Go Client. Newer version will support it.
I don't think accepting all prompts is a good idea, because not every prompt might be a challenge auth prompt.
However, due to my rewrite of the code in question some good time ago, it's now easier than ever to add new prompts values:
http://code.x2go.org/gitweb?p=x2goclient.git;a=blob;f=src/sshmasterconnectio...
(I deliberately didn't add a link to SecurID because it's a proprietary solution. Just to be safe.)
Mihai
On 23.11.2016 02:03 PM, swizz ly wrote:
Thanks for the update. I tried it, it works nicely, many thanks! However, there is a small thing: the user has to be aware that the "Password:" in the first window is ignored and has nothing to do with the two factor authentication, only in the pop-up window with the "Verification code:" should he/she enter the two-factor passcode. It might be somewhat confusing for the first time. As a small suggestion, I would either use the input from the "Password:" field even for the two-factor passcode, or in the pop-up window I would directly copy the prompt from the SSH session, in this case "Enter PASSCODE:" instead of "Verification code:".
I think that's the way PAM works.
Isn't the idea of 2FA to use both the password and a challenge auth token? Users will need to supply their password anyway, so I don't see the problem at hand currently. Do we get two windows, one for the password (or private key passphrase) and one for the verification code, EVEN THOUGH the password/private key passphrase has been set directly in the session config or via an SSH agent?
Copying the prompt actually sounds like a good idea, though, yeah.
Mihai
-
Buddy Butterfly -
ilukeberry -
Mihai Moldovan -
Nick Owen -
swizz ly