Am Dienstag, 25. Januar 2011 schrieb John A. Sullivan III:

On Tue, 2011-01-25 at 16:52 +0100, Martin Steigerwald wrote:

...

Hi!

I installed X2goserver one into a Debian Squeeze VM under VMware ESX today. Since we use a LDAP server to central user management I integrated it via libpam-ldap and libnss-ldap manually. We also use NFS for home directory so I added that too. Logging into the server via SSH works as expected.

But I get "can't start SSH tunnel" when trying to open a new X2go session with x2goclient.

When I use a SSH key I get messages like this:

Verbindung fehlgeschlagen intraws.of.teamix.net: Unable to connect: /home/ms/.x2go/ssh/socaskpass-M31562 Unable to connect: /home/ms/.x2go/ssh/socaskpass-M31562 Permission denied, please try again. Unable to connect: /home/ms/.x2go/ssh/socaskpass-M31562 Permission denied, please try again. Unable to connect: /home/ms/.x2go/ssh/socaskpass-M31562 Permission denied (publickey,password).

I guess this has to do with the usage of NFS.

~/.x2go/ssh is 750 and root is squashed to nobody:nogroup. Thus it is neither the user nor the group. Since

chmod 777 ~/.x2go/ssh

fixes key based login for me, it seems that something of x2go server is using root privileges to access files in the home directory of the user.

Could this be changed to use user rights - root can su to any ? This would work with NFS.

Other questions:

1. Can X2go client be told to use an existing ssh agent which has the right identidy added? A ssh user@intraws works already without asking for the key password, thus if x2goclient uses this ssh-agent it wouldn't need to ask for the passphrase as well.

2. What steps are necessary to integrate x2go with an *existing* LDAP server? x2goldaptools depends on slapd and samba and since we use NFS with an existing LDAP server I want neither of those. LDAP authentification via PAM works already. I can login with SSH and LDAP password of a user. I thought this would be enough for x2go *when* users that use x2go are in the group x2gousers. They are. But in the local group. What additinional steps are necessary?

<snip> Hi, Martin. I suspect your problems may be more NFS related. We are using a separate LDAP server (Centos Directory Server) and have not integrated with the X2Go LDAP tools. All works fine with X2Go. We do use local x2gousers, fuse, and the various pulse groups and simply add the LDAP defined users to them.

When I use SSH key based authentification with that setup, X2go works as expected when I do that chmod 777 on ~/.x2go/ssh before. Thus it seems to me that X2go principally works in that setup.

I only get the "can't start ssh tunnel" message when using password based authentification. But since that works as well via SSH, you are probably right: Maybe with password based authentification X2go tries to create some other file in the home directory in a directory that is still to restricted.

But rather than knocking around at random I'd like to know whats going on. Maybe I'll try to look up what X2go does exactly more closely to get an idea, I just asked here in case somebody knows more already.

Just for kicks, have you tried it with a local home directory rather than NFS? We use iSCSI for ours so all the file system semantics and security are as if our storage was local. Good luck - John

We decided for NFS for a reason. Everywhere else we use NFS or Samba and I do not want to introduce a island solution to our infrastructure.

BTW with LDAP integration I didn't yet mean automatic client configuration and such although something like that would be nice. As a first step I just like user authentification via passwords work at all. But until then we can also used SSH key based authentification.

Thanks,

Martin Steigerwald - team(ix) GmbH - http://www.teamix.de gpg: 19E3 8D42 896F D004 08AC A0CA 1E10 C593 0399 AE90

Am Dienstag, 25. Januar 2011 schrieb Gerry Reno:

On 01/25/2011 10:52 AM, Martin Steigerwald wrote:

...

I guess this has to do with the usage of NFS.

~/.x2go/ssh is 750 and root is squashed to nobody:nogroup.

What happens when you mount without root squashed? It probably works.

If x2go is using root to access user's home directory then this would cause a problem with NFS.

I think it would make the issue go away, but we do not want to run (insecure) NFS without rootsquash. Then chmod 777 to ~/.x2go/ssh and probably (is it needed?) ~/.x2go as well IMHO is the less invasive approach.

Thanks,

Martin Steigerwald - team(ix) GmbH - http://www.teamix.de gpg: 19E3 8D42 896F D004 08AC A0CA 1E10 C593 0399 AE90

Hi Mike,

Am Mittwoch, 26. Januar 2011 schrieb Mike Gabriel:

On Mi 26 Jan 2011 10:55:08 CET Martin Steigerwald wrote:

...

I think it would make the issue go away, but we do not want to run (insecure) NFS without rootsquash. Then chmod 777 to ~/.x2go/ssh and probably (is it needed?) ~/.x2go as well IMHO is the less invasive approach.

You are talking about the x2goserver side, aren't you.

The x2goserver package is currently undergoing a complete rewrite due to some security breaches reported a few days ago on this list.

As far as I know, Alex managed to get rid of all sudo calls in the x2goserver package. (which is also a blessing for the auth.log which got spammed with plenty of sudo log entries before).

The rewrite might solve your issues and it will be out for testing in a couple of days (AFAIK).

However, on the todo list still (i.e. my personal todo list as contributor) is taking a look at x2goprint which also uses sudo calls. These do also fail on NFS volumes (esp. when mounted with one of Kerberos's krb5<x> security mechanisms).

Good to read. Then I will just be looking forward to that new version and retest then. We do not need client side printing as we have a central CUPS server and network printers.

Thanks,

Martin Steigerwald - team(ix) GmbH - http://www.teamix.de gpg: 19E3 8D42 896F D004 08AC A0CA 1E10 C593 0399 AE90