Configuring the SSH Server

SSH servers listen for incoming connections on TCP Port 22 by default. As such, Port 22 is subject to numerous unauthorized login attempts by hackers who attempt to access unsecured servers. An effective deterrent is to close 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, Aspera recommends setting the TCP port to 33001 and closing TCP/22.

1. Open the SSH configuration file /etc/ssh/sshd_config.
2. Add the TCP/33001 SSH port and close TCP/22.
   Comment out the line for "Port 22" and add a line for "Port 33001":

   #Port 22 
   Port 33001

   Once this setting takes effect:

   • Aspera clients must set the transfer port to 33001 in the GUI, or from the command line use the ascp -P 33001 option.
   • Server administrators should use ssh -p 33001 to access the server through SSH.

Configure SSH for use with HSTS.

/etc/ssh/sshd_config

1. Open the SSH configuration file /etc/ssh/sshd_config.
2. Disable non-admin SSH tunneling.
   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 might have additional instances of AllowTCPForwarding that are set to the default Yes. Review your sshd_config file for other instances and disable if necessary.

   Disabling TCP forwarding does not improve security unless users are also denied shell access, because they can still install their own forwarders. Review your user and file permissions, and see Setting Up Transfer Users for instructions on modifying user shell access.

3. Disable agent forwarding (which is enabled by default).
   Add the following to your SSH configuration file:

   AllowAgentForwarding no 

4. 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 your SSH configuration file and enabling private/public key authentication.

   Note: Before proceeding, configure at least one non-root, non-transfer user with a public key to use to manage the server. This is because in other server-securing steps, root login is disabled and Aspera recommends that transfer users are restricted to aspshell, which does not allow interactive login. This user and public key is what you use to access and manage the server as an administrator.

   PubkeyAuthentication yes
   PasswordAuthentication no 

   Note: If you choose to leave password authentication enabled, be sure to advise account creators to use strong passwords and set PermitEmptyPasswords to no.

   PermitEmptyPasswords no

5. If SSH is not going to be used for other purposes on your system, consider restricting use to an explicit list of allowed HSTS users. By default all users are allowed to log in using the OpenSSH service.
   CAUTION:

   If you are on a Windows Domain, you must use the AllowUsers and AllowGroups configuration options to limit access to the server.
   Use the AllowUsers directive in your SSH configuration file. For example:

   AllowUsers xfer1 xfer2 xfer3 

6. For optimal security, configure SSH to use strong ciphers and MACs (such as the AES and HMAC SHA2 variants). Use the sshd_config directives Ciphers and MACs. Be sure to check which ciphers and MACs are supported by your version of OpenSSH.
   For example:

   Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com
   MACs hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha2-256,hmac-sha2-512
   

7. The SFTP subsystem is not used by HSTS. You can disable it if you so not otherwise need it.
8. Disable root login.
   CAUTION:

   This step disables root access. Before you do so, make sure that you have at least one user account with sudo privileges before continuing, otherwise you may not have access to administer your server.

   By default, OpenSSH allows root logins. However, disabling root access helps maintain a more secure server. Aspera recommends disabling root access by changing the PermitRootLogin assignment to no.

   PermitRootLogin no

   Administrators can use the su command when root privileges are necessary.

9. Start the SSH server to apply new settings.

   # systemctl restart sshd.service

   Or for Linux systems that use init.d:

   # service sshd restart

   Restarting your SSH server does not affect currently connected users.

10. If you have enabled logging, review your logs periodically for evidence of attacks.
    You can view the state of active TCP connections by running the netstat command:

    # netstat -an -p tcp

    Typical output shows multiple, different IP addresses connected to specific ports:

      TCP    10.0.111.200:53402     72.21.81.109:80        CLOSE_WAIT
      TCP    10.0.111.200:53865     173.194.202.188:5228   ESTABLISHED
      TCP    10.0.111.200:53876     10.0.9.16:445          TIME_WAIT
      TCP    10.0.111.200:55164     208.85.40.20:443       ESTABLISHED
      TCP    10.0.111.200:55335     207.200.35.240:443     ESTABLISHED
      TCP    10.0.111.200:55444     67.199.110.81:443      ESTABLISHED
      TCP    10.0.111.200:56278     104.24.11.90:443       ESTABLISHED

    If your server is under attack, you might see output similar to the following, in which the same IP address attempts to connect to contiguous ports (hundreds or thousands of times) and the connection is timing out (reporting a status of TIME_WAIT):

      TCP    10.0.111.200:53402     72.21.81.109:60974      TIME_WAIT
      TCP    10.0.111.200:53865     72.21.81.109:60975      TIME_WAIT
      TCP    10.0.111.200:53876     72.21.81.109:60976      TIME_WAIT
      TCP    10.0.111.200:55164     72.21.81.109:60977      TIME_WAIT
      TCP    10.0.111.200:55335     72.21.81.109:60978      TIME_WAIT
      TCP    10.0.111.200:55444     72.21.81.109:60979      TIME_WAIT
      TCP    10.0.111.200:56278     72.21.81.109:60980      TIME_WAIT

    If you see this kind of output, review /var/log/auth.log or /var/log/secure (depending on your system configuration) to determine the source and cause.

    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 identify attacks, take the following steps:

    • 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).

Aspera recommends that you configure transfer-server authorization to use a host-key fingerprint to prevent server impersonation and man-in-the-middle (MITM) attacks. Aspera clients can verify the server's authenticity before starting a transfer by comparing the trusted SSH host key fingerprint (obtained directly from the server admin or through an Aspera client web application) with the host key fingerprint that is returned when the connection is made.

1. Open the SSH configuration file /etc/ssh/sshd_config and set the appropriate SSH key type.
   The HostKey directive can be set to specify various SSH key types. The type you choose must conform to the requirements of the server's intended clients.

   If you are going to use the server with any of the following product releases, you must modify your configuration to use RSA encryption. If you do not, you will get an error for mismatched fingerprints, and your transfers will fail:

   • IBM Aspera Connect 3.10 or earlier
   • IBM Aspera Drive 3.2 or earlier
   • IBM Aspera Command-Line Interface (CLI) 3.9 or earlier
   • IBM Aspera Cargo 3.2 or earlier

   HostKey /etc/ssh/ssh_host_rsa_key
   #HostKey /etc/ssh/ssh_host_ecdsa_key
   #HostKey /etc/ssh/ssh_host_ed25519_key
   

   If you are going to use your server with later versions of these clients, then use the following configuration:

   #HostKey /etc/ssh/ssh_host_rsa_key
   HostKey /etc/ssh/ssh_host_ecdsa_key
   #HostKey /etc/ssh/ssh_host_ed25519_key
   

2. Restart the SSH server to apply new settings.
   The commands for System D and System V (init.d) systems are:

   # systemctl restart sshd.service 

   # service sshd restart 

3. Restart the noded service to activate your changes.
   Run the following commands to restart asperanoded:

   # systemctl restart asperanoded

   or for Linux systems that use init.d:

   # service asperanoded restart