Securing your SSH Server

Edit online

Keeping your data secure is critically important. Aspera strongly encourages taking additional steps to set up and configure your SSH server so that it's protected against common attacks.

These steps include:

Changing the TCP port.
Restricting user access.

Changing the TCP Port

Most automated robots try to log in to 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 secure your SSH server against potential threats, including changing the default port for SSH connections from TCP/22 to TCP/33001.

It is 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 by using the default port 33001. However, if the connection fails, the application attempts the connection using port 22.

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

Locate and open your system's SSH configuration file.
The SSH configuration file can be found in the following location:
```
/etc/ssh/sshd_config
```
Add a new SSH port.
Note: Before changing the default port for SSH connections, 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 opening TCP/33001 and disabling TCP/22 to prevent security breaches of your SSH server.

To enable TCP/33001 while your organization is migrating from TCP/22, open port 33001 from your sshd_config file (where SSHD is listening on both ports). As demonstrated by this exercise, SSHD is capable of listening on multiple ports.
```
...
Port 22
Port 33001
... 
```
Once your client users have been notified of the port change (from TCP/22 to TCP/33001), you can disable port 22 in your sshd_config file. To disable TCP/22 and use only TCP/33001, comment out "Port 22" in your sshd_config file.
```
...
#Port 22
Port 33001
...
```
```
$ ascp -P 33001 ...
```
Disable nonadmin SSH tunneling.
Note: The following instructions 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 is not available; update 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 nonadmin SSH tunneling, open your SSH Server configuration file, sshd_config, with a text editor.

Add the following lines to the end of the file (or modify them if they exist):
```
...
AllowTcpForwarding no
Match Group root
AllowTcpForwarding yes
```
Depending on your sshd_config file, you might have additional instances of AllowTCPForwarding that are set to the default Yes. Review your sshd_config file for other instances and disable.

Note that disabling TCP forwarding does not improve security unless users are also denied shell access, as they can always install their own forwarders. Review your user and file permissions, and see the following instructions 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, 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 to advise account creators to use strong passwords. Be sure also to set PermitEmptyPasswords 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 use the su command if root privileges are needed.

Restart the SSH server to apply new settings.

When you finished updating your SSH server configuration, you must restart or reload the SSH service to apply your new settings. Note that restarting or reloading SSH does not impact currently connected users.

To restart or reload your SSH server, run the following commands:

OS Version	Commands
Red Hat, zLinux (restart)	`$ sudo service sshd restart`
Red Hat (reload)	`$ sudo service sshd reload`
Debian (restart)	`$ sudo /etc/init.d/ssh restart`
Debian (reload)	`$ sudo /etc/init.d/ssh reload`

Review your logs periodically for attacks.
Review your SSH log periodically for signs of a potential attack. Locate and open your syslog—for example, /var/log/auth.log or /var/log/secure. Depending on your system configuration, syslog's path and file name might vary.

Look for invalid users in the log, especially a series of login attempts with common usernames 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 identify attacks, do the following:
- Double-check the SSH security settings in this topic.
- Report attackers to your ISP's email address for abuse reports (often abuse@your_isp.com).

Configuring Transfer Server Authentication

Open the transfer server's aspera.conf file.
The file is found in the following location:
```
/opt/aspera/etc/aspera.conf
```
Locate the <server> section, and add the <ssh_host_key_fingerprint> or the <ssh_host_key_path> option.
Note: When the HTTP fallback feature is enabled and the client "falls back" to HTTP, a fingerprint specification in aspera.conf enforces server SSL certificate validation (HTTPS). Validation fails if the server has a self-signed certificate; a properly signed certificate is required.
- <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, Isilon, 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 is 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_path>
```
After modifying aspera.conf, restart the node service by running asperanoded:
```
# /etc/init.d/asperanoded restart
```