How to connect to your Linux VM

Introduction
Step 1: Add a firewall rule
Step 2: Configure the port forwarding
Testing the new connection
Virtual machine security, SSH and passwords

 

Introduction

A basic Internet connection to a VM requires you to add a firewall rule, and to set the port forwarding configuration. This procedure is illustrated here for the case of creating a connection for an SSH (secure shell) login to a Linux VM.

The VM needs to be attached to a 'Local with Internet Gateway' network. For more information, see How to create a network for your VDC.

For the case of a Windows VM, see How to connect to your Windows VM.

It is also possible to use the VDC built-in load balancer: see How to manage load balancing rules for your VDC.

Important

When you create a Local with Internet Gateway network, its firewall is initially set with no inbound or outbound connections.

Take care that a VM has a secure root password, before you activate any Internet connection. For virtual machine templates that use a public default password you will need to reset the password via the VM console.

 

Step 1: Add a firewall rule

Click Network on the left-hand menu. Then click the name of the network you wish to use. Then click View IP Addresses, and from the list click the public IP address you wish to use (one Gateway network can support multiple public IP addresses). You should now see the Details sub-panel for the IP address. Finally, click the Configuration tab to show the Configuration sub-panel:

Click View all under Firewall. This shows the list of firewall rules for this specific IP address (initially there are none).

Use the Add input boxes at the top and specify:

  • Source CIDR: the IP addresses which will be granted access to the VM, using CIDR notation; for example, use 0.0.0.0/0 for access from any Internet location.

  • Protocol: TCP by default.

  • Start Port and End Port: for SSH, both of these are set to 22.

Click Add to create the firewall rule. It should appear in the list of firewall rules.

If you need to change the rule, you must delete it and Add a new rule.

The firewall rule allows network traffic to pass from the Internet into the VDC network. The next step is to specify what should happen to the traffic within VDC.

Step 2: Configure the port forwarding

If necessary, see the start of Step 1 to navigate to the IP Configuration sub-panel.

Click View all under Port Forwarding. The shows the list of port forwarding configurations for this specific IP address (initially there are none).

Use the Add row at the top and specify:

  • Private Port start and end: for SSH, both of these are set to 22.

  • Public Port start and end: for SSH, set these to 22.

  • Protocol: TCP by default

Click Add.

An Add VM dialog will appear. Use the selection buttons to select the VM for this port forwarding rule.

Click Apply. The new forwarding configuration should appear in the list.

If you need to change the configuration, you must delete it and Add a new configuration.

By using different Public Port numbers it is possible to create a set of forwarding rules so that a user may use the same connection protocol (HTTP, for example) but connect to different VMs through the same IP address. Or, different ports on the same VM: for example, if you have a web server (running on port 80) and an experimental web server (running on port 8080). For more details, see How to manage NAT and port forwarding for your VDC.

Testing the new connection

On your own computer, use the 'ssh' command line program in Linux to open a connection, using the public IP address you have just configured. For the example case it will look like (the IP address has been xxx'd out for reasons of privacy):

$ ssh root@213.xxx.xxx.xxx

You will of course need to know the VM root password, which is displayed when the VM is first deployed.

On a Windows computer, you can use an SSH application such as the PuTTY telnet/SSH client [www.putty.org] to open a secure shell connection.

Take care that a VM has a secure root password, before you activate any Internet connection. For virtual machine templates that use a public default password you will need to reset the password via the VM console.

Virtual machine security, SSH and passwords

Virtual machines exposed to the Internet are subject to frequent malicious attacks and this will start to happen within one or two minutes of the VM first being connected. When the SSH login port is exposed, secure passwords are vital, for all user accounts of the VM.

There are several ways of increasing the level of security for the VM. It tends to be the case that anything which increases the difficulty of malicious attack also makes it more difficult for legitimate users to access the VM, and therefore security measures can get loosened. However it is important to keep in mind that all VMs on the Internet are subject to malicious attack at all times, not only those which are acting as 'public' servers for websites.

Port forwarding rules can be used to improve security by setting the Source CIDR to a restrictive value based on specific public IP addresses or address ranges. For example, you only allow the public IP addresses assigned to the networks at your company premises. In this case, users who are away from the premises will need to have access to some form of proxy service to connect to an authorised public IP address.

You can reduce the number of malicious login attempts via SSH by not using the default port 22 but instead setting the firewall Port and Public Port to a non-standard value (so-called 'obscurity by security'): the port numbers 49152 to 65535 are 'dynamic'/'private' ports and can be used for any purposes (see IANA port number registry). The disadvantage of this is that both users and automated services expect the SSH port default and may not be able to use other ports (for example, if a user's computer is behind a restrictive firewall that only exposes port 22 for egress).

A better approach to improving SSH access security is to consider disabling SSH password-based access for a VM and requiring the use of SSH 'key pair authentication'. See VDC API: How to use SSH key pairs for setting this up in VDC. In this case the possibility of malicious access by matching key pairs is vanishingly small. Nearly all automated programs based on the SSH protocol make use of key pair authentication as the default.

You should also consider whether continuous SSH access via the Internet is needed and use the VDC Control Centre or API to open the firewall only when it is required.