Securing your SSH Server

Secure your SSH server to prevent potential security risks.

Introduction

Keeping your data secure is critically important. Aspera strongly encourages you to take additional steps in setting up and configuring your SSH server so that it is protected against common attacks. Most automated robots will try to log into your SSH server on Port 22 as root, with various brute force and dictionary combinations in order to gain access to your data. Furthermore, automated robots can put enormous loads on your server as they perform thousands of retries to break into your system. This topic addresses steps to take in securing your SSH server against potential threats, including changing the default port for SSH connections from TCP/22 to TCP/33001.

Why Change to TCP/33001?

It is well known that SSH servers listen for incoming connections on TCP Port 22. As such, Port 22 is subject to countless, unauthorized login attempts by hackers who are attempting to access unsecured servers. A highly effective deterrent is to simply turn off Port 22 and run the service on a seemingly random port above 1024 (and up to 65535). To standardize the port for use in Aspera transfers, we recommend using TCP/33001.

Note: Remote Aspera application connections attempt to establish an SSH connection using the default port 33001. However, if the connection fails, the application attempts the connection using port 22.

The following explains how to change the SSH port to 33001 and take additional steps for securing your SSH server. The steps all require root access privileges.

Locate and open your system's services file
Open your services file with a text editor. You will find this file in the following system location:
```
/etc/services
```
Add new SSH port
Note: Before changing the default port for SSH connections, please verify with your network administrators that TCP/33001 is open.

The OpenSSH suite included in the installer uses TCP/22 as the default port for SSH connections. Aspera recommends taking the following measures:
- Open TCP/33001 and keep TCP/22 open until users are notified they should switch to TCP/33001.
- Once users are notified, block TCP/22 to prevent security breaches, and only allow traffic on TCP/33001.
Note: When changing the SSH port, you must also update the SshPort value in the <WEB...> section of aspera.conf. Please refer to Configuring your Web UI Settings for details.

To enable TCP/33001, open 33001 within your /etc/services file. Note that you cannot put two entries of the same name in the /etc/services file to make SSHD run on two ports. Thus, you need to add a second SSH process to the /etc/services file (e.g. ssh2), which is demonstrated in the sample below.
```
...
ssh   22/tcp      # SSH Remote Login Protocol
ssh2  33001/tcp   # SSH Remote Login Protocol (secure port)
...
```
Save a backup of the /System/Library/LaunchDaemons/ssh.plist file to ssh.plist.bak. Then edit ssh.plist to use the second SSH port (which is demonstrated in the sample below).

ORIGINAL:
```
...
<key>Sockets</key>
     <dict>
        <key>Listeners</key> 
        <dict>
            <key>SockServiceName</key>
            <string>ssh</string>
            <key>Bonjour</key>
            <array>
                <string>ssh</string>
                <string>sftp-ssh</string>
            </array>
        </dict>
     </dict>
...
```
NEW:
```
...
<key>Sockets</key>
     <dict>
        <key>Listeners</key> 
        <dict>
            <key>SockServiceName</key>
            <string>ssh</string>
            <key>Bonjour</key>
            <array>
                <string>ssh</string>
                <string>sftp-ssh</string>
            </array>
        </dict>
        <key>Alternate Listeners</key>
        <dict>
            <key>SockServiceName</key>
            <string>ssh2</string>
        </dict>
     </dict>
...
```
You need to restart your SSH service to apply the changes. Restarting your SSH server will not impact currently connected users. To restart your SSH Server, go to System Preferences > Sharing. Uncheck and then re-check Remote Login from the left panel. In the Allow access for: option, select All users, or specify individual user accounts for the fasp connections.

Once your client users have been notified of the port change (from TCP/22 to TCP/33001), you can modify /etc/services so that the only open SSH port is TCP/33001.

Note: Aspera recognizes that disabling the default SSH connection port (TCP/22) may affect your client users. When you change the port, ensure that you advise your users on configuring the new port number. Basic instructions for specifying the SSH port for fasp file transfers can be found below. To change the SSH port for Aspera Client, click Connections on the main window, and select the entry for your computer. Under the Connection tab, click Show Advanced Settings and enter the SSH port number in the SSH Port (TCP) field.

To make an impromptu connection to TCP/33001 during an ascp session, specify the SSH port (33001) with the -P (capital P) flag. Please note that this command does not alter ascp or your SSH server's configuration.
```
$ ascp -P 33001 ...
```
Disable non-admin SSH tunneling
Note: The instructions below assume that OpenSSH 4.4 or newer is installed on your system. For OpenSSH 4.4 and newer versions, the "Match" directive allows some configuration options to be selectively overridden if specific criteria (based on user, group, hostname and/or address) are met. If you are running an OpenSSH version older than 4.4, the "Match" directive will not be available and Aspera recommends updating to the latest version.

In OpenSSH versions 4.4 and newer, disable SSH tunneling to avoid potential attacks; thereby only allowing tunneling from root users. To disable non-admin SSH tunneling, open your SSH Server configuration file, sshd_config, with a text editor.The file is located as follows:
```
/etc/sshd_config
```
Add the following lines to the end of the file (or modify them if they already exist):
```
...
AllowTcpForwarding no
Match Group root
AllowTcpForwarding yes
```
Depending on your sshd_config file, you may have additional instances of AllowTCPForwarding that are set to the default Yes. Please review your sshd_config file for other instances and disable as appropriate.

Note that disabling TCP forwarding does not improve security unless users are also denied shell access, as they can always install their own forwarders. Please review your user and file permissions, as well as refer to the instructions below on modifying shell access.
Update authentication methods
Public key authentication can prevent brute force SSH attacks if all password-based authentication methods are disabled. For this reason, Aspera recommends disabling password authentication in the sshd_config file and enabling private/public key authentication. To do so, add or uncomment PubkeyAuthentication yes and comment out PasswordAuthentication yes.
```
...
PubkeyAuthentication yes
#PasswordAuthentication yes
PasswordAuthentication no
...
```
Note: If you choose leave password authentication enabled, be sure PermitEmptyPasswords is set to "no".
```
PermitEmptyPasswords no
```
Disable Root Login
OpenSSH defaults to allowing root logins; however disabling root access helps you to maintain a more secure server. Aspera recommends commenting out PermitRootLogin yes in the sshd_config file and adding PermitRootLogin No.
```
...
#PermitRootLogin yes
PermitRootLogin no
...
```
Administrators can then utilize the su command if root privileges are needed.
Restart the SSH server to apply new settings

When you have finished updating your SSH server configuration, you must restart the server to apply your new settings. Go to Apple menu > System Preferences > Sharing. Uncheck and then re-check Remote Login from the left panel. In the Allow access for: option, select All users, or specify individual user accounts for the fasp connections.

Restrict user access

Restricting user access is a critical component of securing your server. By default, all user accounts are allowed to browse and read all files on the server. To limit a user's access to a portion of the system, set the account's shell to the Aspera secured shell (aspshell) and create a document root (docroot) for that user. The aspshell permits only the following operations:

Run Aspera uploads and downloads to or from this computer.
Establish connections in the application and browse, create, delete, rename or list contents.

The following instructions demonstrate how to change a user account so that it uses the aspshell. Keep in mind that this is an example, and there may be other ways to do so for your system. Go to Apple menu > System Preferences > Accounts, select Click the lock to make changes and enter admin credentials to allow changes. Right-click the account to set up aspshell and select Advanced Options.

Under Advanced Options, locate Login Shell and replace the default value (/bin/bash) with /usr/bin/aspshell (note that the Mac installer creates a symlink between /usr/bin/aspshell and /Library/Aspera/bin/aspshell).

You can also restrict a user's file access by setting a Document Root (docroot). You can set a user's docroot from the product GUI by going to Configuration > Users > Docroot > Absolute Path. Input a path in the blank field and ensure that Override is checked.

Set up the docroot.

Once you have set the user's docroot, you can further restrict access by disabling read, write and/or browse. You may do so via the product GUI (as shown in the screenshot above).

Field	Description	Values
Absolute Path	The area of the file system (i.e. path) that is accessible to the Aspera user. The default empty value gives a user access to the entire file system.	Path or blank
Read Allowed	Setting this to `true` allows users to transfer from the designated area of the file system as specified by the Absolute Path value.	`true` `false`
Write Allowed	Setting this to `true` allows users to transfer to the designated area of the file system as specified by the Absolute Path value.	`true` `false`
Browse Allowed	Setting this to `true` allows users to browse the directory.	`true` `false`

Review your logs periodically for attacks
Aspera recommends reviewing your SSH log periodically for signs of a potential attack. Launch (Macintosh HD) > Applications > Utilities > Console and locate the file /private/var/log/secure.log (FILES > private/var/log > secure.log).

Look for invalid users in the log, especially a series of login attempts with common user names from the same address, usually in alphabetical order. For example:
```
...
Mar 10 18:48:02 sku sshd[1496]: Failed password for invalid user alex from 1.2.3.4 port 1585 ssh2
...
Mar 14 23:25:52 sku sshd[1496]: Failed password for invalid user alice from 1.2.3.4 port 1585 ssh2
...
```
If you have identified attacks:
- Double-check the SSH security settings in this topic.
- Report attacker to your ISP's abuse email (e.g. abuse@your-isp).
Set up transfer server authentication
For transfers mediated by a web application, the client browser sets up the context for the transfer using an HTTPS connection to the server, and then delegates the transfer to the Aspera fasp engine. The fasp engine then connects to the transfer server. In so doing, it needs to ensure the server's authenticity in order to protect the client against server impersonation and man-in-the-middle (MITM) attacks.

To verify the authenticity of the transfer server, the web app passes the client a trusted SSH host key fingerprint of the transfer server. When connecting to the transfer server, the client confirms the server's authenticity by comparing the server's fingerprint with the trusted fingerprint.

To configure transfer server authentication, open the transfer server's aspera.conf file:
```
/Library/Aspera/etc/aspera.conf
```
Locate the <server> section, and add either the <ssh_host_key_fingerprint> or the <ssh_host_key_path> option.
- <ssh_host_key_fingerprint>
  Use this option to specify the fingerprint itself:
```
<ssh_host_key_fingerprint>fingerprint</ssh_host_key_fingerprint>
```
  To retrieve the SSH fingerprint, locate the transfers server's public or private key, and run the following command on a Linux, Mac, or other UNIX computer:
```
# cd /etc/ssh
# cat ssh_host_rsa_key.pub | cut -d' ' -f2 | base64 -d | sha1sum | cut -d' ' -f1
```
  The following is an example SSH fingerprint:
```
43:51:43:a1:b5:fc:8b:b7:0a:3a:a9:b1:0f:66:73:a8
```
  By convention, Aspera uses a hex string without the colons ( : ). For example:
```
435143a1b5fc8bb70a3aa9b10f6673a8
```
  The aspera.conf setting for this key would then be as follows:
```
<ssh_host_key_fingerprint>435143a1b5fc8bb70a3aa9b10f6673a8
</ssh_host_key_fingerprint>
```
- <ssh_host_key_path>
  Use the key-path option to specify the transfer server's public or private key file and its location. The fingerprint will be extracted automatically.
```
 <ssh_host_key_path>key_file</ssh_host_key_path> 
```
  On most Linux systems, the SSH keys are located in /etc/ssh. On OSX, the SSH keys are located in /etc. The following example uses a Linux server's public RSA key:
```
<ssh_host_key_path>/etc/ssh/ssh_host_rsa_key.pub</ssh_host_key_fingerprint>
```
After modifying aspera.conf, be sure to restart the node service by running asperanoded:
```
# sudo launchctl stop com.aspera.asperanoded
# sudo launchctl start com.aspera.asperanoded
```