Server Side

This section covers the server-side concepts, administration, and utilities.

System Requirements

The minimum recommended resources on a system are 2 CPU cores and 2 GB of RAM.

Quick Start

The following examples provide basic usage of KasmVNC with the tools provided.

# Start a session and be guided to setup a user and select a default desktop environment
vncserver

# Start a session with the mate desktop environment
vncserver -select-de mate

# Add a new user with read/write permissions
vncpasswd -u my_username -w -r

# Tail the logs
tail -f ~/.vnc/*.log

# Get a list of current sessions with display IDs
vncserver -list

# Kill the VNC session with display ID :2
vncserver -kill :2

Users

There are operating system users and then there are KasmVNC users. These are two separate users with different security contexts. The KasmVNC user and associated credentials provide access to the KasmVNC session and specify what KasmVNC permissions the user has.

An operating system user starts an KasmVNC session using vncserver. The desktop session running within KasmVNC is running as the operating system user that started the session. The user then accesses the KasmVNC session via a web browser using the KasmVNC credentials. Once logged into the desktop, any actions performed on the desktop in the context of the operating system user that started vncserver.

Permissions

The KasmVNC permissions include read, write, and owner. A user can exist with no permissions. Permissions can be changed during runtime by using the Kasm developer API. A user with no permissions will be allowed to connect, but will not receive rendering updates and will not have permissions to provide input or make changes such as resizing. A user with read permissions will receive a rendering of the screen, but will not have permissions to send keyboard/cursor input or modify the session parameters. Users with write access will have full control of the session, to the extent allowed by the server-side configuration. KasmVNC does support multiple users with write permissions. Write access also provides read access, it is not possible to provide only write access.

Owner permissions only provide access to make API calls to the KasmVNC developer API. The owner permission does not imply read or write permissions. The developer API allows adding users and changing user permissions on the fly. Locally you can use kasmvncpasswd to manage KasmVNC users, however, changes using kasmvncpasswd will not be applied instantly like they are with the Developer API.

Authentication

Authentication is provided for by HTTPS Basic Auth. Safari browsers do not support passing Basic Auth credentials through web socket connections, therefore, Safari is currently not supported when the client connects directly to KasmVNC.

Network

KasmVNC has a built in web server. The desktop rendering is transmitted via a web socket connection by default. KasmVNC also supports WebRTC UDP under certain circumstances.

WebRTC

This feature is currently considered experimental. KasmVNC has built in support for WebRTC UDP data channel, which provides better performance over high latency links. KasmVNC currently does not support TURN servers, which is required if the server is behind NAT. A server that is behind static NAT, should work without a TURN server. KasmVNC does support STUN, which is used by the client and server to discover their public IPs as seen by the internet. You can statically set KasmVNC’s public IP address with the network.udp.public_ip option. This can be used on private networks, to bypass STUN.

Utilities

The following are man pages for the various tools/binaries installed with KasmVNC.