|Installation and Upgrades|
Aspera also recommends restricting user access to the server. For more information, see Setting Up Users .
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.
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 Administrator privileges.
C:\Program Files[ (x86)]\Aspera\Enterprise Server\etc\sshd_config
Port 22 Port 33001
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
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 Administrators 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.
PubkeyAuthentication yes #PasswordAuthentication yes PasswordAuthentication no
Click Start > Control Panel > Administrative Tools > Services . Locate the OpenSSH Service and click Restart.
> netstat -an -p tcp
Typical output shows multiple, different IP addresses connected to specific ports:
TCP 10.0.111.200:53402 18.104.22.168:80 CLOSE_WAIT TCP 10.0.111.200:53865 22.214.171.124:5228 ESTABLISHED TCP 10.0.111.200:53876 10.0.9.16:445 TIME_WAIT TCP 10.0.111.200:55164 126.96.36.199:443 ESTABLISHED TCP 10.0.111.200:55335 188.8.131.52:443 ESTABLISHED TCP 10.0.111.200:55444 184.108.40.206:443 ESTABLISHED TCP 10.0.111.200:56278 220.127.116.11: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 18.104.22.168:60974 TIME_WAIT TCP 10.0.111.200:53865 22.214.171.124:60975 TIME_WAIT TCP 10.0.111.200:53876 126.96.36.199:60976 TIME_WAIT TCP 10.0.111.200:55164 188.8.131.52:60977 TIME_WAIT TCP 10.0.111.200:55335 184.108.40.206:60978 TIME_WAIT TCP 10.0.111.200:55444 220.127.116.11:60979 TIME_WAIT TCP 10.0.111.200:56278 18.104.22.168:60980 TIME_WAIT
If you see this, review your logs to determine the source and cause.Go to Start menu > Control Panel > Administrative Tools > Event Viewer. In the left panel, open the file tree and select Windows Logs > Application. To see only SSH Server events, in the Actions panel, click Filter Current Log. In the Event sources field, enter sshd. You may also apply other conditions when needed.
You can review the logs in the Event Viewer main window, or you can save the logs by clicking Save Filtered Log File Asin the Action pane. Save the log file in .txt or .csv format.
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.
If you identify attacks, take the following steps:
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.
To retrieve your SHA-1 fingerprint, run the following command:
> ssh-keygen -E sha1 -l -f "C:\Program Files[ (x86)]\Aspera\Enterprise Server\etc\ssh_host_rsa_key.pub"
The output lists the strength of the key, the hash algorithm, the fingerprint, the name of the user and hostname, and the type of key, similar to the following, in which 7qdOwebGGeDeN7Wv+2dP3HmWfP3 is the fingerprint.
2048 SHA1:7qdOwebGGeDeN7Wv+2dP3HmWfP3 system@host_name (RSA)
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:
Go to Control Panel > Administrative Tools > Computer Management > Services and Applications > Services, click Aspera NodeD, and click Restart.