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 Serverbroker-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