--- myst: html_meta: "description lang=en": "Connecting Kasm Workspaces to fixed KasmVNC, or RDP, SSH, VNC endpoints." "keywords": "Kasm, RDP, VNC, SSH, Fixed, Static, KasmVNC" "property=og:locale": "en_US" --- ```{title} Servers ``` # Servers Kasm Workspaces provides session management and rendering of sessions for fixed systems or auto scaled systems that support either KasmVNC, RDP, SSH, or VNC. [Workspaces](../workspaces.md) can be created and assigned to [Groups](../groups.md), providing users access to the servers from their dashboard. ```{figure} /images/compute/servers.webp :align: center **Servers List** ``` ## Create Server To create a new server, navigate to Infrastructure->Servers and click Add. Fill in the required information about the server. In order for the server to be accessible to users, a [Workspace](../workspaces.md) must be created and then add the Workspace to a [Group](../groups.md). ```{eval-rst} +-----------------------------------------+--------------------------------------------------------------------------------------+ | Property | Description | +-----------------------------------------+--------------------------------------------------------------------------------------+ | Enabled | Show and allow connections to this server. | +-----------------------------------------+--------------------------------------------------------------------------------------+ | Friendly Name | The server name displayed to users. | +-----------------------------------------+--------------------------------------------------------------------------------------+ | IP/Hostname | The IP or Hostname used to connect to the server. | +-----------------------------------------+--------------------------------------------------------------------------------------+ | Connection Type | Whether to use KasmVNC, RDP, SSH, or VNC. | +-----------------------------------------+--------------------------------------------------------------------------------------+ | Connection Port | Which port to connect to the server on. | +-----------------------------------------+--------------------------------------------------------------------------------------+ | Connection Username | The username to use to connect to the server. | +-----------------------------------------+--------------------------------------------------------------------------------------+ | Connection Password | The password to use to connect to the server. | +-----------------------------------------+--------------------------------------------------------------------------------------+ | Use User SSH Key | (Optional) This only applies to the SSH Connection type. When selected Kasm uses the | | | User's SSH Keys to authenticate against the server. | +-----------------------------------------+--------------------------------------------------------------------------------------+ | Connection Private Key | (Optional) This only applies to the SSH Connection type. This is the private key to | | | be used to authenticate to the server. | +-----------------------------------------+--------------------------------------------------------------------------------------+ | Connection Private Key Passphrase | (Optional) This only applies to the SSH Connection type. This is the passphrase of | | | the Private Key specified above. | +-----------------------------------------+--------------------------------------------------------------------------------------+ | Connection Info | (Optional) Additional connection info that needs to be passed to the server. | | | For more information see the Connections section of the | | | :doc:`global settings <../settings>` | +-----------------------------------------+--------------------------------------------------------------------------------------+ | Max Simultaneous Sessions | The maximum amount of sessions that can connect to the server at a time. | +-----------------------------------------+--------------------------------------------------------------------------------------+ | Deployment Zone | Which deployment zone to set for the server. | +-----------------------------------------+--------------------------------------------------------------------------------------+ | Pool | Which pool does the server belong to. | +-----------------------------------------+--------------------------------------------------------------------------------------+ ``` (windows_single_sign_on)= ### Single Sign-On to Windows Systems via LDAP When users login to Kasm via [LDAP Authentication](../ldap.md), they are able to create sessions to Windows systems that are joined to the same Active Directory domain and are configured for SSO credential pass-through. In the above table covering the configuration fields for Servers are the **Connection Username** and **Connection Password** fields. Place the value `{sso_username}` in the **Connection Username** field and place the value `{sso_cred}` in the field **Connection Password**. This requires that all users accessing this server are authenticated to Kasm using LDAP authentication. See our Windows Deployment Guide video for a walk through of this topic and more. ## Authentication Options When Connecting to an SSH Server Kasm Workspaces has the ability to connect to arbitrary SSH servers. It can use SSH key or password authentication. There are a few combinations of options on the Server edit screen that can be selected. The server can be configured to use: - Username/password authentication - Username and select the `Use User SSH Key` to send the username and private key stored with the Kasm user. - Username and a pasted in private key, optionally including a passphrase if the key requires one. Place the value `{sso_username}` in the **Connection Username** field and check the **Use User SSH Key** checkbox and Kasm Workspaces will send the user's Kasm Workspaces username along with the user's Kasm Workspaces SSH key allowing easy multiple user support on SSH servers. There are some restrictions on the ssh keys supported that are enforced by the connection proxy library used for the ssh server connections: The SSH key must be an ssh-rsa key in PKCS1 format (i.e. the header of the key starts with `-----BEGIN RSA PRIVATE KEY-----`) with a key size of 2048. In addition, some newer Linux distributions such as Ubuntu 22.04 LTS will not accept ssh-rsa keys by default. To work around this edit the `/etc/ssh/sshd_config` file on the target server and add these two lines to the config. ```{parsed-literal} HostKeyAlgorithms +ssh-rsa PubkeyAcceptedKeyTypes +ssh-rsa ``` ## SSH session continuity Kasm Workspaces uses Guacamole to provide SSH connectivity for SSH server definitions. Guacamole does not provide the ability to resume SSH sessions. This means that when disconnecting from an SSH Workspace such as when clicking **Workspaces** from the control panel it will not be possible to resume the same session when clicking **Resume** and a fresh SSH session will be created. This also applies to disconnections caused by network interruptions. To avoid this a user can utilize a utility such as screen/tmux to have a persistent terminal session on the server. ### Tmux Connection Settings Example This is an example of how it would be possible to configure the Kasm connection settings for a Server to use tmux to have a preserved environment on an SSH server. ```json { "guac": { "type": "ssh", "settings": { "font-size": "11", "color-scheme": "gray-black", "font-name": "monospace", "scrollback": "1000", "command": "tmux a || tmux" } } } ``` ### Screen Connection Settings Example This is an example of how it would be possible to configure the Kasm connection settings for a Server to use screen to have a preserved environment on an SSH server. ```json { "guac": { "type": "ssh", "settings": { "command": "screen -R my_session" } } } ``` (vmware_templates)= ## Creating Templates For Use With The VMware vSphere Provider When using the VMware vSphere provider the administrator must create templates on the cluster for the provider to clone from. ### Linux Templates When creating Linux VM templates ensure that: - VMware tools, either the official version or the open-vm-tools are installed. - If SSH access is desired ensure that a public SSH certificate is installed on the machine, and use the matching private key when creating the [Autoscale documentation](autoscale_configuration). - If creating this template for use in a Docker Agent pool take note of the primary ethernet interface name as that will be needed for the [autoscale startup scripts](https://github.com/kasmtech/workspaces-autoscale-startup-scripts). #### Troubleshooting Linux Startup Script Execution The startup script will be copied to a temporary directory on the Linux host, this is usually /tmp. inside the temporary directory VMware will create a folder named vmware-root_ followed by a set of random numbers e.g. vmware-root_437-1849036237. Then VMware will create the script file inside this directory also randomly named e.g. vmware119.sh. VMware does not provide a logging facility for executing these scripts but the script writer could log important events by creating an adjacent file and writing to it. If the script fails during testing of the Autoscale/vm-provider configuration the administrator can bring up VMware console access to the cloned machine, find the script in the temporary directory and manually execute the script to observe it's output. ### Windows Templates When creating a Windows VM template ensure that: - VMware tools is installed. - Remote desktop has been enabled on the VM. - The startup script entered into the [VM Config Provider](./vm_providers.md) will be run as a Powershell script, so ensure that unrestricted remote scripting is enabled. - If desired ensure that the [Kasm Windows Service](../../how_to/windows_service.md) is installed, this will make uploads and downloads available from the [Kasm Control Panel](../../user_guide/control_panel.md). #### Troubleshooting Windows Startup Script Execution The startup script will be copied to a temporary directory on the Windows host, this is usually the directory pointed to by %TEMP%. This environment variable must be resolved when logged in as the user the script will be executed as to give an accurate location. Inside the temporary directory VMware will create a folder named vmware-root_ followed by a set of random numbers e.g. vmware-root_437-1849036237. Then VMware will create the script file inside this directory also randomly named e.g. vmware119.sh. VMware does not provide a logging facility for executing these scripts but the script writer could log important events by creating an adjacent file and writing to it. If the script fails during testing of the Autoscale/vm-provider configuration the administrator can bring up VMware console access to the cloned machine, find the script in the temporary directory and manually execute the script to observe it's output.