Sometimes the x2go client will no longer connect to the x2go server on your target VM. Verify that:

1. x2go client is configured correctly [/scs/2021/ssh-connection-with-x2go-remote-desktop-client/]
2. Internet connection & Cisco VPN is working [Remote Access (VPN)]
3. ssh connection (non-graphical) is working to the server [Secure Shell (ssh)]

If all 3 are verified then it is likely your x2go session on the target machine (server VM) is the problem and then continue with the following steps.

Here are the steps to delete all the x2go settings on the server:

1. ssh to your server using a non-graphical ssh client (putty for Windows for example). NOTE, once logged in you can check the file: .xsession-x2go-HOSTNAME-errors if that shows anything obvious. If not proceed.
2. Then remove the following files in your root (~) homedirectory:

• • rm -rf .x2go
  • rm .Xauthority
  • rm .xsession-x2go*
  • rm -rf .cache/sessions
  • rm -rf .cache/fontconfig
  • sudo rm -rf /tmp/.X11-unix
  • sudo rm -rf /tmp/.ICE-unix

3. Now you have reset your x2go settings on the server: logout and try connecting again using your x2go client.

NOTE: It’s also worth checking if your instance ran out of disk space? If your disk is full then x2go can no longer write session data to disk and it will no longer let you login. Use the command ‘df -h’ and check how much space you left on your VM? If you are at 100% you will need to free space on your disk.

The post How to reset your x2go session on the server side appeared first on School of Computer Science.

DEPRECATED – x2go is not used on newer images created since the Fall of 2024 – Instead use TurboVNC with our newer images

Download x2go:

You can find a video demo of these instructions here:

Install x2go, following the application’s instructions

Open x2go

• On Windows you may get a warning to allow x2go to access the network (firewall rule change); approve the request. This may also pop-up each time you create a new session (described below), so you may have to approve the request more than once.

Create a new session in x2go by clicking Session -> New Session
The key settings that must be entered in the x2go session settings window that pops up are:

• Host: 134.117.216.10
• Login: student
• Session Type: XFCE – This is used for many of our course images, but your course may have a different preferred desktop. Another common one we use is LXDE

Once the settings are entered, click OK

In x2go you will see a new session connection:

Click on the session to initiate the connection:

• You will be asked to enter the instance’s password
• If it is the first time you are connecting to the instance with x2go, you will be asked if you trust and approve connecting to the host. Again, approve the connection

Finally, a window should pop-up connected to the desktop:

The post SSH Connection with x2go Remote Desktop Client appeared first on School of Computer Science.

SSH Connection Using an SSH Terminal Client

We recommend using PowerShell on Windows as the quickest way to open an SSH terminal connection, but there are many SSH terminal tools out there you use.

NOTE: This example uses putty, but the settings are the same for any terminal tool that supports SSH.
Putty can be installed through the Windows Store

You can find a video demo of these instructions here:

Enter settings into putty:

Enter username / password:

IMPORTANT: – Remember that the first time you login, you will be prompted to change your password. See the Login Credentials section at the top of this page for details.

You should see a similar prompt when you successfully connect:

The post SSH Connection Using the putty SSH Terminal Client appeared first on School of Computer Science.

Step 1: Set up Multiple Compute Nodes
Step 2: Update hostname of the compute nodes
Step 3: Set up the SSH Keys and Environment
Step 4: Replicate the SSH Environment
Step 5: Replicate /etc/hosts file
Step 6: Test Your Passwordless SSH Connections!
Graphic: Set up of SSH Enabled Multi-node Compute Environment
Copy Files Between Remote Nodes

This guide will take you through the steps of setting up a multi-node compute environment that uses ssh keys to support scripts and computing tools that communicate and move data between the compute nodes.

You can learn more general information about passwordless ssh login here:
Passwordless SSH With Key Pairs

Step 1: Set up Multiple Compute Nodes

For this example, we will set up the following nodes (instances) on:

• primary-node – main control node for your multi-node environment; this node will typically have an OpenStack floating IP address assigned so that you can access the environment from the ÐÓ°ÉÔ­´´ network (either an on-campus computer or your home device using VPN).
• node-1, node-2, node-3, …, node-n – compute nodes (as many as required)

Instructions for setting up nodes (instances), assigning floating IPs, and connecting to instances can be found here: OpenStack Step-by-Step Guide

Step 2: Update hostnames of the compute nodes

In this step, you will need to edit two system files: /etc/hostname and /etc/hosts. To do so, you will need to open them with root privileges by prefixing your command with the sudo command. For example, you can use the simple nano editor to edit one of the files like so:
sudo nano /etc/hostname – sudo checks that your user is authorized to run commands as root and will prompt for your password

• On the primary-node and node-1 -> node-n, edit the /etc/hostname files to have a suitable name for each host. After a reboot, this will be reflected in the system name that appears on the console, the shell and the desktop. This is helpful for making sure you do not make changes to the wrong system!
• On the primary-node, edit the /etc/hosts file to include IP HOSTNAME records.
  
  For example:
  
  192.168.5.123 primary-node

192.168.5.179 node-1

192.168.5.65 node-2

192.168.5.221 node-3
  
  NOTE 1: You will need to find the IP address of your nodes from either the OpenStack interface or running the commands ipconfig or ip addr on the node itself
  
  NOTE 2: On the SCS OpenStack, the IP address will ALWAYS start with 192.168.x.x

Step 3: Set up the SSH Keys and Environment

Setting up a passwordless ssh key environment will allow your scripts or compute tools to communicate and move data between all of your compute nodes. This tutorial will not go into all the background about ssh key pairs, but you can learn more about that in this guide: Passwordless SSH With Key Pairs.

Steps for setting up the ssh key pair environment:

1. Login to the primary-node as the user that will be running the scripts or compute tools and run a terminal or shell (student user works fine on most of our images)
2. Create an SSH public/private key pair:
   
   ssh-keygen
   
   Do NOT enter the a filename (leave the default /home/student/.ssh/id_rsa)
   
   Do NOT enter a passphrase (leave it blank)
   
   This will create the public and private keys:
   
   ~/.ssh/id_rsa – private key
   
   ~/.ssh/id_rsa.pub – public key
3. Copy the user’s public to that user’s account on every node (including the primary-node itself):
   
   This is done using the ssh-copy-id command. You will need to say yes when prompted to verify the host-key (if this is the first time you are connecting to that node). You will also be prompted to enter the password for the user’s account
   
   ssh-copy-id node-1

ssh-copy-id node-2

ssh-copy-id node-3

...

ssh-copy-id node-n

ssh-copy-id primary-node – This will ensure that the ~/.ssh/known_hosts file has the host key for EVERY node AND the primary-node. It will also add the user’s public key to the ~/.ssh/authorized_keys file on the primary-node, meaning the private key can ALSO unlock the primary-node, in addition to node-1 -> node-n

SSH public and private key (key pair) and environment files are now set up
After completing the above steps, all four ~/.ssh/ files should be configured:
~/.ssh/id_rsa – private key
~/.ssh/id_rsa.pub – public key
~/.ssh/authorized_keys – includes the public key (It will be identical to the id_rsa.pub file if no other keys were set up previously)
~/.ssh/known_hosts – includes the host keys for EVERY host (primary-node and node-1 -> node-n)

Step 4: Replicate the SSH Environment

The SSH public and private keys and the environment files can now be COPIED from primary-node to each of node-1 -> node-n
scp ~/.ssh/* node-1:~/.ssh/
scp ~/.ssh/* node-2:~/.ssh/
scp ~/.ssh/* node-3:~/.ssh/
...
scp ~/.ssh/* node-n:~/.ssh/

Step 5: Replicate /etc/hosts file

To make it easier to move between the primary-node and node-1 -> node-n, COPY the /etc/hosts file to each node.
NOTE: Because /etc/hosts is a system file, you will need to first copy the file to each node, then ssh onto the node and use sudo to copy the file to that system’s /etc/hosts

Copy the /etc/hosts file to each node (repeat the below steps for each of node-1 -> node-n:)

1. Copy the /etc/hosts file from the primary-node to node-1:
   
   scp /etc/hosts node-1:~/
2. SSH to node-1:
   
   ssh node-1
3. Move the hosts file you just copied to overwrite the system /etc/hosts file:
   
   sudo mv ~/hosts /etc/hosts
   
   As was the case earlier in this guide, when you edit (or in this case, overwrite) a system file such as /etc/hosts, you need to prepend your command with the sudo command

Step 6: Test Your Passwordless SSH Connections!

You should now be able to ssh between all of your nodes without using a password.

• Test from the primary-node:
  
  ssh node-1

ssh node-2

ssh node-3

...

ssh node-n

ssh primary-node
• Test from at least one of the nodes, such as node-1:
  
  ssh primary-node

ssh node-1

ssh node-2

...

ssh node-n
  
  NOTE: Ideally test all of the systems, but if you have a LOT of them, a few random tests should be sufficient
  
  NOTE: Some tools and scripts only require that you can ssh from the primary-node to node-1 -> node-n, so you would not need to do this step.

Graphic: Set up of SSH Enabled Multi-node Compute Environment

Graphical overview of setting up a multi-node compute environment, using ssh keys for inter-node connections:

Copy Files Between Remote Nodes

Once you have the ability to ssh between computers, either using passwords or the ssh keys as setup above, it is easy to copy files the computers. If you do have ssh keys setup allowing you to ssh with no password, then these tools will not prompt for a password. Here are a few example tools:

• Copy files with rsync: rsync options source_path destination_path

rsync -r -v ~/Downloads student@node1:~/Downloads
  
  
  
  • -r – tells rsync to copy files recursively (all sub-files and folders)
  
  
  • -v – tells rsync to show the files as they are copied
  
  
  • ~/Downloads – tells rsync to copy the files in the user’s Downloads folder
  
  
  • student@node1:~/Downloads – tells rsync to copy the files to the remote server node1 using the student user account, and copy the files into the student user’s Downloads directory
  
  
  
  

  rsync is a powerful tool as you can specify various options that control what is copied. For example, it will not “sync” files that are already up-to-date on the destination node.
  

• Copy files with scp: scp options source_path destination_path

scp -r -v ~/Downloads student@node1:~/Downloads
  
  
  
  • -r – tells rsync to copy files recursively (all sub-files and folders)
  
  
  • -v – tells rsync to show the files as they are copied
  
  
  • ~/Downloads – tells scp to copy the files in the user’s Downloads folder
  
  
  • student@node1:~/Downloads – tells rsync to copy the files to the remote server node1 using the student user account, and copy the files into the student user’s Downloads directory
  
  
  
  

  scp is not “tunable” to precisely control what files are copied. It also does not check if a file is already up-to-date as the destination.
  

The post Using SSH Keys to Support Multi-node Compute Tools & Scripts appeared first on School of Computer Science.

OpenSSH is now included with Windows 10 (as of October 2018). Depending on your version of Windows, the feature may or may not be installed by default.

Step 1: Check if SSH is enabled

To check if SSH is enabled on your system, open a command prompt and end the command ssh. If it provides you with help for using SSH, it is already enabled! You should be able to follow the Linux instructions using the ssh-keygen command from the command prompt.

Step 2: Enable the SSH client

SSH is considered an optional feature of Windows and may not be installed by default. To enable it, follow these steps:

• Open your settings
• Go to Apps > Apps and Features > Manage Optional Features
• Check the list to see if “OpenSSH Client” is already enabled
• If you do not see “OpenSSH Client”, click Add a Feature
• Find OpenSSH Client in the list of features and click Install

You should now see OpenSSH Client in your list of features and be able to run the ssh-keygen command similar to the Linux instructions.

Note: If you do not see OpenSSH Client as an available optional feature, your version of Windows 10 may not support it. Instead of OpenSSH, you can use PuTTYgen to generate your .ppk file and then connect using PuTTY.

PuTTY Alternative

Traditionally on Windows, people have used a tool called to ssh to a remote system. PuTTYgen is an included tool that provides a graphical interface for generating PuTTY ppk files (public/private keys). This is a file that contains both private and public keys, readable by PuTTY. If you would like to use PuTTY, you can find more information on generating keys on the .

The post Enable OpenSSH on Windows 10 appeared first on School of Computer Science.

Why extend a disk?
What is LVM Partition
Check Existing Space
Extend Partition using the Script
Extend Partition Manually

Why extend a disk?

Many of our images (primarily on openstack) do not grow their partition/file system size automatically if you choose a flavor (openstack resource definition) that allocates more disk space to your instance than was available in the original image. It is possible to use tools such as cloud-init to do this automatically. However, in our public images, which we use on multiple environments (openstack, virtualbox, vmware, etc), we find cloud-init can sometimes cause issues. Instead, we have scripts designed to resize the partitions for the user.

What is LVM Partition

Historically, many of our standard images for Openstack and VirtualBox virtual machines use LVM (Linux Logical Volume Manager) to provide the disk volume for the operating system, as well as additional storage volumes (if applicable). LVM makes it easy to resize and re-purpose space within Linux, usually without even requiring a reboot.

You can learn more about LVM here: – LVM is available for most Linux distros.

Check Existing Space

Before you can enlarge the disk, first you have to check to see if it is possible:

Check physical disk size versus the partition or LVM size (using fdisk):

• Run fdisk, to see if there is more space available that could be added to the LVM:
  
  sudo fdisk -l
• In most of our basic images, this should show just a single physical device, such as:
  
  Disk /dev/vda: 32 GiB, 34359738368 bytes, 67108864 sectors – 32 GB physical disk
• It will also show the main partition, typically the LAST partition (which could be used by LVM):
  
  Regular partition example:
  
  Device Start End Sectors Size Type

/dev/vda1 2048 4095 2048 1M BIOS boot

/dev/vda2 4096 16777182 16773087 8G Linux filesystem
  
  In this case it is an 8 GB partition (/dev/vda2)
  
  LVM Example:
  
  Device Boot Start End Sectors Size Id Type

/dev/vda1 2048 16777215 16775168 8G 8e Linux LVM
  
  In this case it is an 8 GB partition (/dev/vda1)
• And finally it will also show the LVM itself if LVM is being used:
  
  Disk /dev/mapper/COMPbase--vg-root: 8 GiB, 8585740288 bytes, 16769024 sectors

So, in this case, the Physical disk is 32 GB, but only 8 GB are currently allocated to the LVM, and no other partitions are using the rest of the space for anything else. So we can extend it!

Extend Partition using the Script

If you are using one of our standard SCS images, either for OpenStack or for VirtualBox virtual machines, it usually comes with a small script called extend-disk.sh. The script is found in the home directory of the student user under the extend-disk folder. NOTE:Older images may have the script called extend-lvm.sh, found in the extend-lvm folder in the student home directory

To run the script:

• Open a terminal
• Go to the directory with the script, usually: cd ~student/extend-disk/
• Enter: sudo ./extend-disk.sh /dev/vda – NOTE: the /dev/vda may be different on your system. It is the device you found in Check Existing Space above

That’s it! Now when you run fdisk, you should see the last partition is the full size of the physical disk: sudo fdisk -l.

To update or download the script:

• If you do not have the script, you can get it using git:
  
  git clone https://git.scs.carleton.ca/git/extend-disk.git
• If you have the script and it was pulled from the git repository, then you can pull updates:
  
  cd extend-disk go into the extend-disk git folder
  
  git pull to pull the updates
  
  NOTE: If you are unsure if it was pulled from the git repository, then check if there is a .git hidden folder in the extend-disk folder (check for hidden folders with ls -la); If not, then you need to clone the repository using the git clone command above.

Extend Partition Manually

Here are the steps to manually extend the partition and the filesystem, including for the LVM case.

NOTE: We assume the same setup as the above Check Existing Space

• Extend the physical drive partition:
  • sudo fdisk /dev/vda – Enter the fdisk tool to modify /dev/vda
    
    NOTE: End each one letter command by pressing [Enter]; if the instructions do not specify a specific response to a question, just press [Enter] to accept the default
  • p – p command prints the disk info, same as running fdisk -l /dev/vda
  • d – d command delete the last partition (usually /dev/vda1 or /dev/vda2 on our images)
  • n e n command creates a new partition; e makes that an extended partition
  • Optional: t – t changes the type of partition. NOTE: This should not be required as fdisk should use the same type as was removed. You can also enter L when prompted to find the list of codes for the types. Make sure to use the same type as was listed by fdisk for the partition you removed in the earlier d step.
    
  • w – w writes the changes to disk and exits fdisk
• IF using LVM: Modify (extend) the LVM:
  • Tell LVM the physical partition size has changed: sudo pvresize /dev/vda1
  • Find the actual path of the LVM logical volume: sudo lvdisplay – The LV Path is the value needed
  • Tell LVM to extend the logical volume to use all of the new partition size: sudo lvextend -l +100%FREE /dev/COMPbase-vg/root – Using the LV Path from above
• Resize the file system:
  
  sudo resize2fs /dev/vda2 or for lvm: sudo resize2fs /dev/COMPbase-vg/root

That’s it! Now, when you run sudo fdisk -l, it will show that the LVM is using all of the space on the physical disk!

The post Extend Linux Disk (disk space) appeared first on School of Computer Science.

SSH allows you to securely connect to remote computers and virtual machines. With SSH, you can use a computer remotely through the terminal, transfer files between the server and client, and even run graphical programs using X11 forwarding. By default, you will connect to SSH servers using the username and password associated with your account on the server; however, you can also set up something called an SSH Key Pair, which allows you to connect easily and securely.

What is an SSH Key Pair?

As the name suggests, a key pair consists of two keys: the public key and the private key. While you can connect to SSH servers using your account username and password, you can also connect using a username and an authorized key pair associated with that username.

Your public key acts like a personalized padlock that resides on servers. It is an encrypted file that you can publicly distribute to different servers. When you associate a public key to your account, you are saying that anyone who can unlock the public key can also unlock my account without the need for my account password.

Your private key is the key that unlocks your public key and is kept on the client. As the name suggests, this is a file that should be private to you and only you. While many private keys do not have file extensions, you may see private keys with the .pem file extension when using cloud services.

To protect your private key, you always add a passphrase – a password to protect your private key. If you are using a key for automated purposes on a secured network, then you may need to create a key that does NOT have a passphrase. But this is only in specific circumstances. Any key used for remote access from public networks should always have a passphrase.

Why use Key Pairs?

Key pairs offer a number of conveniences when you use remote services:

• Provides a way of authenticating that is less vulnerable to password guessing and brute force attacks
• Distribute your public key to get system access without ever setting up passwords
• Have a different key pair for each device and simply delete the public key from the server to revoke the old devices’ access
• Create a key pair (without a passphrase) for scripts or tools like MPI, Hadoop, etc. so that they can authenticate with other devices without a password prompt
  
  You can find a detailed example of setting up ssh key login for scripts in this article:
  
  Using SSH Keys to Support Multi-node Compute Tools & Scripts

Remember that your public key is truly public; as long as you protect your private key file, you may distribute your public key however you would like. Nobody can do anything malicious with your public key file, so you can use them to create a shared identity across multiple services. The same public key will work across the different services as long as you use the same private key.

Comparing Password vs Key Pair Authentication

Below we show comparisons between the password and key pair authentication mechanisms.
NOTE: These are grossly over-simplified diagrams of how the various technologies work. It is meant to just provide an general idea of the steps involved and what is happening.

Creating Key Pairs

Most operating systems support a tool called ssh-keygen that allows you to create a public/private key pair.

Linux / Apple OSX / Windows 10

1. Open a Terminal window / prompt
   
   On Windows, you can open a Command Prompt or PowerShell
   
   See Enable OpenSSH on Windows 10 if ssh-keygen is not enabled on Windows 10 (older versions do not have it enabled by default)
2. Enter the ssh-keygen -t ed25519 command to open up an interactive prompt that takes you through the steps of creating an SSH key
3. Type a filename for the key, or use the default
   • If you are only using one SSH key pair, you can keep the default (usually ~/.ssh/id_ed25519)
   • If you are creating multiple key pairs for different purposes, you should name it something meaningful (e.g. ~/.ssh/home_github_key)
4. Finally, type your passphrase. You should ALWAYS use a passphrase
   If your key has a passphrase, then if someone somehow gets your private key file, they will still not be able to use it unless they are able to guess your passphrase. In some cases, such as setting up server/application automation (hadoop, MPI, etc), you may want to create a key without a passphrase. But this should NEVER be done for a key used to remote access a system, repository, etc from public networks
   • NOTE: When typing passwords in the terminal, no text will appear while you type — press Enter to continue
5. Your public and private key pair should now be available in ~/.ssh/ or wherever you specified.

Authenticating and Connecting with Key Pairs

Linux / Apple OSX / Windows 10

Authorize your key pair on a remote server

Once you have created your key pair, you need to authorize the key pair to unlock your account.

• Copy your identity (public key) over to the remote server using the ssh-copy-id command:
  
  ssh-copy-id username@remoteservername.ca – substituting your particular username and remote server name (or IP address)
• NOTE: If you created a specific ssh key file (rather than using the default), you can specify it with the -i option:
  
  ssh-copy-id -i <PUBLIC KEY FILE> username@remoteservername.ca – giving your public key file

Connect to the remote server using the key pair

Once you have authorized the key pair you can connect with it.

• Connect using your default ssh key using the ssh command:
  
  ssh username@remoteservername.ca – substituting your particular username and remote server name (or IP address)
• NOTE: If you created a specific ssh key file (rather than using the default), you can specify it with the -i option:
  
  ssh -i <PRIVATE KEY FILE> username@remoteservername.ca – This time specifying your private key file

For information about connecting with PuTTY, visit the Connecting to OpenStack with SSH and PuTTY quick-start guide.

Advanced Topic: Configuring SSH

Once you start using SSH for many different services and making use of multiple key pair identities, it may be useful to start using an SSH configuration file.

SSH configs help simplify tasks:

• Giving servers simpler aliases, e.g. typing ssh openstack rather than ssh 134.117.x.x
• Using different identities with different servers without needing to specify each time
• Forward ports with SSH to access remote services, such as forwarding a Jupyter Notebook server from a remote port to a local port

There is a lot of information available online about setting up ssh configurations for different purposes. Your ssh configuration is typically in your home ssh folder, such as ~/.ssh on Linux or %USERPROFILE%/.ssh/ on Windows, with OpenSSH installed. If there isn’t a file called config you can make one. Below is a sample SSH configuration to have one passwordless private key for Github and another passworded key for OpenStack, with parts that need to be switched for individual use.

Using the above file, you could then connect to your OpenStack instance using ssh openstack rather than ssh -i ~/.ssh/openstack.pem username@134.117.x.x and git will also use the correct identity file when using SSH and working with GitHub.com.

The post Passwordless SSH With Key Pairs appeared first on School of Computer Science.

Our OpenStack images that include desktops are preconfigured to run the turbovnc server. This server allows you to connect to your OpenStack instance using the TurboVNC client, which provides a very fast and secure desktop environment.

Step 1: Download TurboVNC Client for your OS

Download TurboVNC: . Find the package for your computer’s operating system (OS)

• For macOS on M-series chips, select the TurboVNC-version_number–arm64.dmg
• For macOS on Intel chips, select the TurboVNC-version_number–x86_64.dmg
• For Windows 64-bit (most cases), select the TurboVNC-version_number–x64.exe
• For Windows 32-bit (old devices), select the TurboVNC-version_number–x86.exe
• For Linux, you can select a suitable source file, rpm package, etc

Step 2: Install the TurboVNC Client

Install the TurboVNC client that you downloaded. In macOS and Windows, this should be as easy double-clicking on the installer file that you downloaded in the previous step.
Some Important Notes:

• On Windows 11, the TurboVNC client does not automatically setup start-menu or desktop shortcuts to access the tool. The easiest way to open it is to click on the Windows Start button, and then type TurboVNC in the search bar. The TurboVNC Viewer App will appear under the Best Match list. If you Right-click on the icon, it will give you the option to Pin to Start. This can make it easier to find in the future.

Step 3: Open a TurboVNC desktop connection

NOTE: TurboVNC cannot be used to connect to our instances for the first time as it does not support the first logon password reset. See Login Credentials & First Login below for more information

Open the TurboVNC client app. You will see a windows similar to this:

• Fill in the VNC server field to be the format username@floating-ip-address (see the Login Credentials below for information about your username and password)
• Click the Connect button
• Enter your Password when prompted
• That’s it! In a few seconds a window should open showing your desktop connection, similar to the image below

Example TurboVNC Desktop Window: Your TurboVNC Desktop Windows should look similar to the image below:

Optional: Reconnect to a TurboVNC Session

If you want to reconnect to a TurboVNC session, you can simply close the TurboVNC window, without actually logging out of the desktop. This will save your session for you to connect to at a later time.

• If you have a TurboVNC session already running when you connect, you will see an additional window after the password prompt
• To reconnect to a previous session, click the Connect button next to the appropriate session (there could be more than one)
• To start a new session, click the New Session button.

BUG: TurboVNC connections will fail after an update

If TurboVNC is updated on your instance, you may have a situation where connections from the TurboVNC client subsequently fail. This is caused by a bug where TurboVNC is unable to identify the proper Linux Window Manager being used on your instance.

Solution:

1. Use an ssh terminal session to connect to your instance
2. On the instance, open the file: /etc/turbovncserver.conf and add the line $wm = "xfce"; to the end of the file. Close the file and save it
3. Attempt to connect to the instance using your TurboVNC client

The post SSH Connection with TurboVNC appeared first on School of Computer Science.