Permitting remote access to your dedicated server

Here at Anchor we believe in a security philosophy based on Defense in depth which uses a theory of adding multiple layers of security. This is done to ensure that no single breech in a security system will result in a compromise.

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

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 (terminal services)) is only ever going to be accessed by a set number 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. Whilst this is certainly not a method to verify identity it is undoubtedly one of the more fundamental controls you can put in place to stop unauthorised hosts from even trying.

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

Alternatively, if you have an unmanaged machine then this can be made using one of any of the following methods:

Filtergen Recommended - Anchor uses filtergen exclusively on all Linux hosts
iptables
Windows Firewall

PAM Restrictions

The next restrictions that we implement are part of PAM (Pluggable Authentication Modules) which come part of most Linux distributions. There are effectively two files which are commonly in use to restrict access to either FTP or SSH on a per account basis. These are contained within the following two files:

```
 /etc/security/ssh_users
```
```
 /etc/security/ftp_users
```

The format of these files is quite simple and takes the following format.

To allow access:

```
 +:USER:HOST-CONNECTING-FROM
```

To deny access:

```
 -:USER:HOST-CONNECTING-FROM
```

The best way to describe this is through an example file:

+:testguy:ALL
+:testgirl:192.168.0.100
+:test:example-host.com.au
-:ALL:ALL

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

Line 1: Permit the user 'testguy' to log in from any host.
Line 2: Permit the user 'testgirl' to log in from the IP address 192.168.0.100
Line 3: Permit the user 'test' to log in from any IP address that the machine reverse resolves to example-host.com.au
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-based restrictions

This is typically the final and most commonly-used method of identifying a user. User based restrictions generally work based on the end user providing a valid username and password combination to access the machine.

To add a user account to a Linux host the following process would be used:

Ensure that the username is unique on the machine using a command similar to:
```
 id USERNAME
```
This should return with error such as "No such user" to indicate that the user doesn't exist.
Add the user account to the machine using a command similar to one of the following:

ssh access:
```
 useradd -g users USERNAME
```
ftp access:
```
 useradd -g users -s /bin/ftponly USERNAME
```
In both these instances the USERNAME needs to be substituted with the user you wish to create Next a password can be set:
```
 passwd USERNAME
```
To enhance the security of the machine even further, SSH keys should be used in preference to standard username+password authentication.