Last updated: 31 Jul 2020

• Overview
• Configured SSH Service
• Troubleshooting

Overview

Secure Shell (SSH) is a protocol for creating an encrypted terminal session between a client computer and an SSH service. The terminal session allows the client to login to the remote service, enter commands and see the results of those commands. An SSH package usually also includes a secure copy (scp) command and facility for copying files between client and remote computers.

SSH Service

An SSH service (or "daemon" in Linux terminology) is the remote computer program that waits for a connection from a client computer, negotiates encryption with it, and issues a login prompt for the client to respond to. Depending on how the service and client are set up, either passwords or public keys are used for login control. Once a user name is received, if passwords are used, a password prompt is sent to the client, and when the client returns the password, it is compared to one stored on the computer where the SSH service is running; if it is a match, the user is logged in an provided a command prompt. If keys are used, the public key provided is used with the private key, and if it is allowed, a command prompt is issued to the client.

An ssh service, often called sshd, is popular on Linux systems and is often part of the default packages installed. It is not necessarily enabled and started; enabling it in systemd terminology tells Linux to start the service every time Linux is started, and is only done once. On some Linux systems, this looks like:

systemctl enable sshd

Starting the ssh service initializes it with a host key the first time it is started, and runs the service according to its configuration file (e.g., /etc/ssh/sshd_config). On some Linux systems, this looks like:

systemctl start sshd

The ssh service also normally starts up the stfpd service, which provides the remote end of the secure copy facility.

More recent versions of Windows 10 (1809 and above) and Windows Server 2019 have a Microsoft OpenSSH service package that can be installed and works similarly to the Linux version.

An ssh service normally listens for connections on port 22.

SSH Clients

The ssh client is normally the ssh command, with scp being the secure copy command. On Windows, sometimes PuTTY is installed; it uses plink for an ssh command, putty for its ssh command window, and pscp for its secure copy command. More recent versions of Windows 10 (1809 and above) and Windows Server 2019 have a Microsoft OpenSSH client package that can be installed (and includes ssh and scp).

Since ssh/scp are common commands, there are many online tutorials one can find about how to use them, and they won't be covered here.

Configured SSH Service

When SET Lab staff create VMs and install guest operating systems (OSes)for classes, teams, individual students or faculty, they normally will enable ssh services within the guest OS so the users will be able to start the VM/guest OS and use an SSH client to interact with the remote server. If you are familiar with command lines, this is a simple and effective way to interact with the guest OS. Any issues with doing so are covered in the Troubleshooting section.

Troubleshooting

However, there are some cases where ssh services are not available:

• The VM is running but the ssh service cannot be connected.

  It could be a BIOS boot problem, a corrupted OS disk, or someone didn't enable or turned off the ssh service. In these cases, see Using the VCL: Remote Manual Interaction.

• No ssh service is installed or available to be installed.

  If you installed the guest operating system yourself from a CD/DVD .iso file or otherwise, you are likely familiar with Using the VCL: Remote Manual Interaction. In that case, you need to install and configure your ssh service, if one is available.

  If an ssh service does not exist for your guest operating system, perhaps you can use an remote desktop service. Otherwise, your only recourse is to follow Using the VCL: Remote Manual Interaction.

• The virtual or real network is not correctly configured.

  SSH service access will only be available from outside the UW campus —unless Husky OnNet VPN is used— if the virtual network interface cards (NICs) can access the internet. Only Network Address Translation (NAT) with port-forwarding enabled or Bridged network methods will work. If all you want to do is use ssh amongst VMs in a private network such as "host-only" or "internal", then those network methods should work.

  Firewalls on the guest OS must have the ssh service port open. Normally, this is port 22, but can be changed by a privileged user of the guest OS.

  For NAT, a unique host port must be established that maps to the guest OS port, and the host's IP address must be used. This mapping is usually done by SET lab staff. If you changed the ssh service port number, the NAT mapping will need to be changed as well.

  For the bridged networking method, one must use the guest OS's IP address, not the host's. The ssh service port number is whatever the default is, or whatever you changed it to be.

Change Log