Securing Your SSH Server

Keeping your data secure is critically important. Aspera strongly recommends taking additional steps to set up and configure your SSH server to protect against common attacks. These steps include the following:
  1. Changing the TCP port.
  2. Restricting user access.
  3. Configuring transfer server authentication.

Changing and Securing the TCP Port

Generally, 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. An effective deterrent is simply to 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, Aspera recommends setting the TCP port to 33001.

The OpenSSH suite included in the installer uses TCP/22 as the default port for SSH connections. Remote Aspera clients attempt to establish an SSH connection with the server on port 33001. However, if the connection fails, the client retries the connection on port 22. Aspera recommends opening TCP/33001 and disabling TCP/22 to prevent security breaches of your SSH server.

  • 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 and allow traffic only on TCP/33001.


  • Before changing the default port for SSH connections, verify with your network administrators that TCP/33001 is open.
  • Before closing port TCP/22, notify users of the change.

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 how to configure the new port number, from the GUI (if available and used) and from the command line.

GUI: To change the SSH port in Desktop Client, click Connections and select the entry for the server whose ports are changing. On the Connection tab, click Show Advanced Settings and enter the SSH port number in the SSH Port (TCP) field.

Command line: Clients running FASP transfers from the command line can specify the port by using the -P 33001 option.

The following steps require root privileges.

  1. Open the SSH configuration file.
  2. Add the TCP/33001 SSH port.
    SSHD can listen on multiple ports, so you can have both TCP/33001 and TCP/22 open. To enable TCP/33001, add the port to your sshd_config file, as in the following example:
    Port 22 
    Port 33001
    Note: When changing the SSH port, you must also update the SshPort value in the <WEB...> section of aspera.conf. For details, see Configuring your Web UI Settings.

    Once your client users have been notified of the port change to TCP/33001, disable TCP/22 and use only TCP/33001 by commenting out "Port 22" in your sshd_config file. For example:

    #Port 22
    Port 33001 
  3. Disable non-admin SSH tunneling.
    These instructions require that OpenSSH 4.4 or newer is installed on your system in order to use the Match directive. Match allows you to selectively override certain configuration options when specific criteria (based on user, group, hostname, or address) are met.

    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 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 the steps below for instructions on modifying user shell access.

  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 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 to leave password authentication enabled, be sure to advise account creators to use strong passwords and set PermitEmptyPasswords to "no".
    PermitEmptyPasswords no
  5. Disable root login.
    By default, OpenSSH allows root logins. However, disabling root access helps maintain a more secure server. Aspera recommends disabling root access by commenting out PermitRootLogin yes in the sshd_config file and adding PermitRootLogin No.
    #PermitRootLogin yes 
    PermitRootLogin no

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

  6. Restart the SSH server to apply new settings.
    To apply your new SSH server configuration settings, you must restart the server. Restarting your SSH server does not affect currently connected users.

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

    $ pfexec svcadm refresh ssh
  7. Review your logs periodically for 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        CLOSE_WAIT
      TCP          TIME_WAIT

    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      TIME_WAIT
      TCP      TIME_WAIT
      TCP      TIME_WAIT
      TCP      TIME_WAIT
      TCP      TIME_WAIT
      TCP      TIME_WAIT
      TCP      TIME_WAIT

    If you see this, review your logs to determine the source and cause.

    Open your syslog, which is located in /var/log/auth.log or /var/log/secure, depending on your system configuration.

    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 port 1585 ssh2
    Mar 14 23:25:52 sku sshd[1496]: Failed password for invalid user alice from 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

Restricting 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.
  • Browse, list, rename, create, or delete contents.
  1. Restrict user permissions with aspshell.
    By default, all system users can establish a FASP connection and are only restricted by file permissions. You can restrict the user's file operations through the aspshell, which permits only the following operations:
    • Running Aspera uploads and downloads to or from this computer.
    • Establishing connections in the application.
    • Browsing, listing, creating, renaming, or deleting contents.

    These instructions explain one way to change a user account so that it uses the aspshell; there may be other ways to do so on your system.

    Modify the passwd file to update user accounts to the aspshell.


    Add or replace the user's shell with aspshell. For example, to apply aspshell to the user aspera_user_1, use the following settings in this file:

  2. Set a user's docroot and restrict read, write, and browse privileges.
    When a user's docroot is empty (blank), that user has full access to your server's directories and files. To restrict the user, you must set a non-empty docroot.

    Run the following command to set a docroot for a specific user:

    #asconfigurator -x "set_user_data;user_name,username;absolute,docroot"

    You can further restrict access by disabling write privileges:

    #asconfigurator -x "set_user_data;user_name,username;write_allowed,false"
  3. Run the asp-check tool to check for potential user-security issues.
    The asp-check tool performs the following secure checks:
    • Identifies full-access users and reports how many exist on the system. The existence of full-access users does not necessarily indicate that your system is vulnerable. However, the system administrator must ensure that the existence of full-access users is intentional.
    • Identifies restricted users and potential misconfigurations, including: incorrect login shell (one that is not restricted via aspshell), SSH tunnel access (which can be used to work around the restricted shell), and docroot settings that allow users to access the home directory.
      Note: A docroot setting that allows access to the home directory is not necessarily a security risk. However, a user with this docroot can download or upload SSH keys and upload .login scripts, which could be used to circumvent other access restrictions. Aspera highly recommends setting the docroot under a user's home directory (such as /home/jane/data) or in an alternate location (for example, /data).

    To run the asp-check tool, run the following command:

    # sudo /opt/aspera/bin/

    Search results are displayed as in the following example. If potential issues are identified, review your users' settings before proceeding.

    Users with full access: 22 (not considered insecure)
    Restricted users: 0
    Insecure users: 0
     - no restricted shell (aspshell): 0
     - docroot above home directory: 0
     - ssh tunneling enabled: 0

Configuring Transfer Server Authentication

For transfers initiated by a web application (such as Faspex, Shares, or Console), the client browser sends the transfer request to the server over an HTTPS connection. The transfer is executed by the Aspera FASP engine on the client machine, which connects to the transfer server by UDP. In so doing, the client machine must 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. The client confirms the server's authenticity by comparing the server's fingerprint with the trusted fingerprint.

  1. Set the host key fingerprint in the transfer server's aspera.conf file.
    Note: Server SSL certificate validation (HTTPS) is enforced if a fingerprint is specified in aspera.conf and HTTP fallback is enabled. If the client "falls back" to HTTP and the server has a self-signed certificate, validation fails. The client requires a properly signed certificate.

    To retrieve your SHA-1 fingerprint, run the following command:

    # ssh-keygen -E sha1 -l -f /etc/ssh/

    The output lists the strength of the key, the hash algorithm, the fingerprint, the file from which the fingerprint was extracted, and the type of key, similar to the following, in which 7qdOwebGGeDeN7Wv+2dP3HmWfP3 is the fingerprint.

    2048 SHA1:7qdOwebGGeDeN7Wv+2dP3HmWfP3 ssh_key_filename (RSA)
    If your version of ssh-keygen does not support the -E option and you are using a Unix-like operating system, you can retrieve your SHA-1 fingerprint by running the following command:
    # cd /etc/ssh # cat | awk '{print $2}' | base64 -d | sha1sum

    To set the SSH host key fingerprint, run the following command:

    # asconfigurator -x "set_server_data;ssh_host_key_fingerprint,fingerprint"

    This command creates a line similar to the following example of the <server> section of aspera.conf:

  2. Restart the node service to activate your changes.
    Run the following commands to restart asperanoded:
    # /etc/init.d/asperanoded restart