Permitting remote access to your dedicated server or VPS

Here at Anchor we believe in a security philosophy called defence in depth, which means using multiple overlapping layers of security. This is done to help ensure that no single security breach in a system will result in a compromise.

This means that when you wish to provide access to your server there are a couple of steps involved.

Note that if you have an unmanaged (Monitor) server from Anchor, the framework we describe here won't have been setup, leaving you free to implement things however you wish.

Firewall restrictions

The first access restrictions you may come up against are firewall-based controls. These will typically be in place if a specific service (such as SSH, FTP or remote desktop) is only ever going to be accessed by a mostly-static set of users. These restrictions are set up for a specific IP address (or a block of IP addresses) to prevent unknown hosts from attempting to connect to the service.

This is nowhere near sufficient on its own, but it goes a long way to reducing your exposed "attack surface", shrugging off indiscriminate would-be attackers that make up the vast majority of unauthorised access attempts on servers.

If you have a Secure or Complete managed server with Anchor then we maintain the firewall for you, so all you need to do is contact support and we will make the required changes.

If you have an unmanaged (Monitor) server then you are able to manage the firewall yourself. For Linux servers we recommend the use of Filtergen to manage your iptables ruleset, or you can use iptables directly if you're keen. For Windows servers you'll be using the built-in Windows Firewall.

PAM restrictions

The next restrictions that we implement are part of PAM (Pluggable Authentication Modules), which comes with most, if not all Linux distributions. We've discussed the mechanisms in greater depth in a separate article if you're interested, but on a managed Anchor server you only need to know about two files for controlling access on a per-user basis:

  • /etc/security/ssh_users for SSH access

  • /etc/security/ftp_users for FTP access

We're using what's called the pam_access module, you can read the system's manpages for more details if needed. The format of these files is simple and takes the following format:

  • To allow access:

  • To deny access:


The best way to understand this is with an example:


In this example above the respective lines will cause the following behaviour:

  • Line 1: Permit the user testguy to log in from anywhere

  • Line 2: Permit the user testgirl to log in from the IP address

  • Line 3: Permit the user test to log in from any IP address that reverse-resolves to

  • Line 4: Denies access to all other users. If you are using PAM-based restrictions you must ensure that this is the very last line in the file.

It is important to note that whilst this can restrict a user from logging on from a specific host, this is configuration is entirely separate from the firewall configuration.

User accounts

Finally, you need to create an account for the user. It might sound obvious, but some admins let users share accounts! This is bad because it makes it difficult to lock people out when they should no longer have access, and destroys any sense of accountability for actions.

A separate user account means everyone has their own username and password and are have some privacy and security from each other. To create a user account on a Linux host:

  1. Ensure that the username is unique on the machine

    This should return with error such as "No such user" to indicate that the user doesn't exist, and the username is available.
  2. Add the user account to the server, the USERNAME needs to be substituted with the user you wish to create

    • For SSH access:

      useradd -g users USERNAME
    • For FTP access:

      useradd -g users -s /bin/ftponly USERNAME
  3. Set a password on the account, you should select a strong password that is unlikely to be guessed or brute-forced

    passwd USERNAME

To enhance the security of the server even further, SSH keys should be used in preference to standard username and password authentication, though it takes a little more work.