The default version of the /etc/x2go/broker/x2gobroker-sessionprofiles.conf configuration file can be viewed here.

The file format is the INI file format. It falls in to a [DEFAULT] section and one or more session profile sections. A minimal setup could look like this.

[DEFAULT]
command=XFCE
fullscreen=true

[staff-server]
host=x2go-staff.intern

[student-server]
host=x2go-student-01.intern

[admin-server]
host=x2go-admin.intern
fullscreen=false
width=1280
height=768

Note that every X2Go Client parameter not given here gets filled in from a hard-coded default configuration.

Some options in the x2gobroker-sessionprofiles.conf file are used to tweak the broker itself. The options are:

X2Go Session Broker normally requires two consecutive logins. One against the session broker, the second against the X2Go Server that the X2Go session will be launched on. The second login (SSH login against X2Go Server) can be automated via the session broker and its agent. For activation of this feature, the special session profile option broker-session-autologin has to be set to true.

• broker-session-autologin: send a private SSH key to X2Go Client that the client then internally uses for SSH pub/priv key based authentication. The X2Go Session Broker will send the SSH public key via the X2Go Session Broker Agent to the X2Go Server
• broker-authorized-keys (optional, normally defaults are ok): full path to the server-side authorized_keys file (on the X2Go server)

If broker-session-autologin is activated, the session broker will create a temporary SSH pub/priv key pair, deploy the private key to X2Go Client and the public key to the X2Go Server that is targeted for X2Go session login.

If a user has been successfully authenticated against the X2Go Session Broker (or a user name has been given via the http request for cases where check-credentials in x2gobroker.conf is set to false) you can use the user's UID, GID and the client address from that the user connects to filter out session profiles.

[DEFAULT]
command=XFCE
fullscreen=true

[staff-server]
host=x2go-staff.intern
acl-groups-allow=staff,admins
acl-groups-deny=ALL
acl-any-order=deny-allow

[student-server]
host=x2go-student-01.intern
acl-groups-allow=students,admins
acl-groups-deny=ALL
acl-any-order=deny-allow

[admin-server]
host=x2go-admin.intern
fullscreen=false
width=1280
height=768
acl-groups-allow=admins
acl-groups-deny=ALL
acl-any-order=deny-allow

The ACL rules work very similar to Apache ACL rules (allow, deny statements in apache2.conf).

To set the order (deny, allow vs. allow, deny), use this parameter

• acl-any-order = {deny-allow|allow-deny} (apply order to any ACL)
• acl-users-order = {deny-allow|allow-deny} (apply order to user ACLs only)
• acl-groups-order = {deny-allow|allow-deny} (apply order to group ACLs only)
• acl-clients-order = {deny-allow|allow-deny} (apply order to client ACLs only)

Furthermore, an aid for selecting the correct order (deny-allow vs. allow-deny):

User ACLs:

• acl-users-allow = <user1>, <user2>, …, <userN>
• acl-users-deny = ALL

Group ACLs:

• acl-groups-allow = <group1>, <group2>, …, <groupN>
• acl-groups-deny = ALL

Client ACLs:

• acl-clients-allow = <subnet-or-ip>, <or-dns-hostname>
• acl-clients-deny = ALL