[X2go-User] Problem Using Cloned Accounts

[Mike Gabriel]

Hi Ted,

On Di 07 Feb 2012 23:49:46 CET  wrote:

> We're trying to see if we can get x2go to work on cloned accounts or  
> ones we create via bash on an Ubuntu server.  FYI - we can start  
> x2go sessions successfully if we create a new user "the normal way"  
> (i.e., by hand using the GUI), create the SSH keys and move them  
> between client (windows) and server.

Ok.

> When we try, however, to create a new user account on the server  
> "programmatically" (either brand new or cloned), we consistently get  
> an error which happens regardless of the technique we use.  As best  
> we can tell, the cloned or programmatically created accounts  
> function fine and as we'd expect except when we try to connect via  
> x2go.

I have encountered such a thing! You have to compare these two account  
types and find the difference. Is basic SSH login working for both  
classes of users? Do you use pubkey auth with X2Go or password auth?

> For example, as root we create an account with "useradd - d  
> /home/<newusername> -m --skel /etc/skel <newusername> (we've also  
> tried to use the same command but clone an account that works with  
> x2go, and have tried a range of other bash "create/clone" code).

What is the shell you provide for new users create the above way?

> The connection is made, we see the black screen with "X2GO" and then  
> the screen goes black and stays that way.  Is this the same problem  
> we've seen on some of the "black screen" posts?

Do you have x2goserver-xsession installed??? If yes, what happens if  
you log in through GDM/KDM locally?

> When we quit, we get an error message:
>
>
> Connection failed head:  cannot open  
> /home/<username>/.x2go/C-XXXXXXXXXXX_stDGNOME-dp32/cmdoutput' for  
> reading:  No such file or directory sed: -e expression #1, char 4:  
> unterminated 's' command cat:

Is the home directory really available on the server? Can the user  
write to it?

> From reading the error message, it looks like somehow a "cmdoutput"  
> file or folder is missing which we don't fine on the working  
> account, so maybe it's written out on the fly.

The cmdoutput is a temporary file placed into the session folder by  
x2goclient. It vanishes once the session if finished (that is: after  
it has failed in this case).

> Is this a permissions issue?  We think we are doing everything

Maybe.

> "identically" with the exception of how we are creating the account  
> (e.g., how we create the ssh keys, copy the id_dsa.pub in authorized  
> keys, add the new user to sshd_config, restart ssh).  We've tried

Note that SSH keys and the .ssh dir need specials permissions to work  
(0600, 0700 resp.).

> comparing the permissions in the two accounts, but are not sure if  
> that is even the issue.

Check the permissions more closely... gut feeling on my side.

> We've checked in our user settings via the GUI and none of the users  
> we've added --either programmatically or through the GUI--are  
> checked in the x2go group though all are listed there and it doesn't  
> seem to matter if we check them.

NOTE: by default, users that are able to login with an X2Go server do  
not need any group membership at all (with SQLite as DB backend).  
Actually, putting real users into the group ,,x2gouser'' is a security  
breech. Same for the ,,x2goprint'' group: do not place members into  
this group either. If you want to have client-side folder sharing,  
users have to be in the fuse group, but that's a different cup of tea.

> When we create a new user/account "programmatically", would this  
> cause problems with the x2go set up for that account?

In many setups here around we auto-create loads of accounts. Not an  
issue here...

Mike

-- 

DAS-NETZWERKTEAM
mike gabriel, dorfstr. 27, 24245 barmissen
fon: +49 (4302) 281418, fax: +49 (4302) 281419

GnuPG Key ID 0xB588399B
mail: mike.gabriel at das-netzwerkteam.de, http://das-netzwerkteam.de

freeBusy:
https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: Digitale PGP-Unterschrift
URL: <http://lists.x2go.org/pipermail/x2go-user/attachments/20120208/1053a8b3/attachment.pgp>