This is an old revision of the document!
Most of you have already used X2Go Client in standalone mode. X2Go Client in standalone mode allows to be configured by the user himself. Normally, the user creates a set of session profiles that allow the user to work remotely on one or more X2Go Servers. See the documentation that explains the usage of X2Go Client.
When X2Go Client is run in broker mode, then it does not allow the local definition of session profiles. The list of session profiles gets provided by the X2Go Session Broker. A session broker is either a HTTP(s) server or an SSH server.
The implementations of the X2Go Session Broker can be manifold as long as the returned result is interpretable by X2Go Client.
If you have access to an X2Go Session Broker, you can launch X2Go Client in broker mode. There are several command line options to configure X2Go Client's broker mode
--broker-name=<name>
: Name of broker to display in X2Go client. This parameter is optional--broker-url=<protocol>://[username@]<host>[:port]/path
: URL of broker. Protocol is “http”, “https” or “ssh”. You can specify an username in URL. In this case it will be pasted in authorization dialog of X2Go Client. URL examples are:--broker-url=https://x2gobroker.org/cgi-bin/x2gobroker.cgi
--broker-url=ssh:user@x2gobroker.org:22/usr/lib/x2go/x2gobroker.pl
*
--broker-ssh-key=<path to key>: Path to SSH key to use for authorization on broker. This parameter is
valid only for SSH broker.
*
--broker-autologin: Use default SSH key or SSH agent for authorization on broker. This
parameter is valid only for SSH broker.
*
--broker-noauth'': Do not ask for user credentials for broker authorizations. This can be useful if you using HTTP(S) broker without authentication. Username will be sent to broker if it specified in broker URL. This option is valid
only for HTTP(S) broker.
===== How X2Go broker work =====
==== Authentication ====
The X2Go client can use different methods of authentication.
On HTTP(S)
broker it could be username and password. On SSH broker a SSH key
authentication can also be used. With both types of broker you can
verify additional parameter “authid”. It is a user defined string which
is saved in file. Path to file can be specified as X2Go Client command
line option “–auth-id”. You can configure your broker not to check user
data as it shown in example above. In such case function checkAccess
should always return 1. In example of SSH-Broker this function is not
called at all. The broker just print “Access granted” to let X2Go Client
know, that authentication is successful. In some setups can make sense
to give access to broker without authentication. For example in LAN if
broker only serve as load balancer for X2Go Servers.
2.2. List of predefined X2Go sessions
After successful authentication on broker, X2Go Client will request list
of predefined X2Go Sessions. This list look just the same as session
file of X2Go Client. The function, that send X2Go sessions to Client
look like:
<code>
sub listSessions
{
print “START_USER_SESSIONS<br>
<br>[ <session 1> ]<br>
option1=value1<br>
….
optionN=valueN<br>
<br>[ <session 2> ]<br>
option1=value1<br>
….
optionN=valueN<br>
END_USER_SESSIONS<br>”;
}
</code>
The options are the same as in X2Go Client configuration file. There is
only a difference in parameters “host” and “key”. And there are two
parameters which are not supported in configuration file “status” and
“usebrokerpass”.
The “host” parameter it is not necessary a hostname of X2Go server. The
actual address of a server will be provided after session selection. It
can make sense in a case of load balancing. The best server will be
chosen after selection and sent to client.
The “key” parameter is also ignored. Key can be provided to client after
selection of session too. However, you can set this parameter with some
value to inform the Client, that passwordless authentication should be
tried, for example: “key=will be provided later”.
Parameter “usebrokerpass” say, that a user password for this session
should not be asked, but broker password should be used instead. It can
be useful if the broker and X2Go Server using same authentication server
and there is no need to ask the same password twice. It is not
recommended to use such authentication with HTTP Broker without SSL
encryption.
Parameter “status” can be one of two values “S” or “R”. It can be used
to say X2Go Client that an instance (or instances) of this session
already running or are suspended on server. X2Go Client will display the
status on the Session button.
2.3. Selecting a session
When predefined sessions are listed in X2Go Client, user can choose a
session from sessions list. The id of chosen session will be sent to
broker and broker send a connection data back to client. It is
responsibility of function “selectSession”:
<code>
sub selectSession
{
my ($user, $sid)=@_;
if($sid eq “123456789”)
{
print “SERVER:x2goserver.org:22\n”;
}
}
</code>
This function send a server address and SSH port for X2Go connection. If
no other data are specified a new X2Go session will be created.
Broker can also send to Client information, that suspended session
should be resumed. In this case broker should also send a session data
to Client:
<code>
sub selectSession
{
my ($user, $sid)=@_;
if($sid eq “123456789”)
{
print “SERVER:phoca:22\n”;
print
“SESSION_INFO:12542|ncryer-53-1348753256_stDstartxfce4_dp24|53|debian|S|2012-09-27T06:40:57|7db77095d8a782f479d509d96f2e3261|188.195.168.12|30004|30005|2012-09-27T06:41:28|ncryer|285|30006|\n”;
}
</code>
Broker can get this data from session database or by executing
“x2golistsessions $user” on X2Go server. If X2Go Client running in
broker mode, it will not verify if there are existing sessions on X2Go
server. It is a responsibility of X2Go Broker. Broker should also
suspend session before providing session data to client if session is
running.
The broker can also provide a SSH Key to client:
<code>
sub selectSession
{
my ($user, $sid)=@_;
if($sid eq “123456789”)
{
print “SERVER:phoca:22\n”;
print “—–BEGIN DSA PRIVATE KEY—–
Proc-Type: 4,ENCRYPTED
DEK-Info: AES-128-CBC,XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
yX7XLwCszCLM1FCYpdIGmM98vuHVcpNlVUBVgNcTxE1XCCnPZPjUXiNnUZPk1lme
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
o1q7Q1YmH43qI18lifjUhGZUTYWKQSsj2Am9bnjqaveV2aMEWymC8J9aJOYLpVZG
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
G1DwWnSRgyJaxRm4Ik0/kh78ioUfkVerXaCf2OKCMyiZBWcsNfvQwDa9MBrZ4rYW
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
VR60OGB7dHy+7ozqkjzuX+uB04GIqPJwG797i26Bo4v7uhbALjMa5qsObqXIPM1S
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXX==
—–END DSA PRIVATE KEY—–”;
}
}
</code>
It can be useful in some cases. It is recommended to transfer such keys
only over encrypted channels. It is also recommended to transfer only
temporary keys, which should be removed from known_hosts after
authorization on X2Go server.