Hemanth Chinnadandluru / Integration & Security
← All Aspera posts

Installing IBM Aspera HSTS 4.4.8 on Linux: a practical step-by-step guide

2026-08Aspera14 min read

Installing IBM Aspera High-Speed Transfer Server is not difficult because of the RPM itself. The real work is making sure Linux, SSH, FASP, the firewall, the transfer user's docroot, licensing and optional Node API configuration all agree with each other. This guide documents the sequence I would use for a clean HSTS installation on Linux so that the first high-speed transfer works without turning the deployment into a firewall troubleshooting exercise.

This walkthrough is written against IBM Aspera High-Speed Transfer Server 4.4.8, released in June 2026. The commands below use an RPM-based Linux system such as RHEL or Rocky Linux as the primary example. HSTS 4.4.8 also supports other Linux platforms, including Ubuntu, Debian, SLES and Amazon Linux, but package-management commands differ.

1. What we are building

The target is a single IBM Aspera HSTS server with a dedicated Linux transfer user. The client establishes the control session over SSH and the actual FASP data transfer uses UDP. For the examples in this post, TCP 33001 is used for SSH and UDP 33001 is used for FASP.

Replace host names, usernames, paths and example rates with values that match your environment. Do not copy passwords, entitlement IDs or token-encryption keys from another environment.

2. Check the supported operating system first

HSTS 4.4.8 supports Linux x86_64 on RHEL 8/9/10, Rocky Linux 8/9/10, Ubuntu 22.04/24.04/26.04 LTS, SLES 15, Debian 11 or later, and Amazon Linux 2023. IBM lists Kernel 4.18+ and glibc 2.28+ for the Linux x86_64 build.

Before copying the installer to the server, collect the basic operating-system information. This is also useful evidence when an installation problem later turns out to be an OS, filesystem or resource issue.

cat /etc/os-release
uname -r
ldd --version
lscpu
free -h
df -h
df -h /opt
ssh -V
sudo -l

Also verify hostname resolution and local host entries. At minimum, /etc/hosts should contain a valid localhost entry, and the HSTS hostname should resolve correctly through DNS or the approved local mechanism.

hostname -f
getent hosts "$(hostname -f)"
grep -n "localhost" /etc/hosts

3. Do not disable security controls just to make the install easier

Older Aspera installation notes often contain instructions such as disabling SELinux or opening a large range of ports while testing. That can hide the actual configuration problem and is a poor production baseline. Check the current state first and make an explicit policy decision with the Linux and security teams.

getenforce
sestatus
systemctl status firewalld

If SELinux is enforcing and SSH is moved from TCP 22 to TCP 33001, the new port may also need to be permitted for the SSH service according to your operating-system policy. Handle that through the approved SELinux configuration rather than disabling SELinux globally.

4. Understand the ports before touching the firewall

This is the part that causes the most confusion in real deployments. An Aspera transfer is not simply "TCP 33001". The SSH control connection and the FASP data stream are different traffic flows.

If SSH on TCP 33001 works but the transfer still stalls or falls back, check UDP 33001 before changing the Aspera configuration.

For a simple firewalld-based server using TCP/UDP 33001, the local rules can look like this:

firewall-cmd --permanent --add-port=33001/tcp
firewall-cmd --permanent --add-port=33001/udp
firewall-cmd --reload
firewall-cmd --list-ports

If the Node API is required, open TCP 9092 only from the trusted management or application network rather than exposing it broadly.

5. Download HSTS 4.4.8 from IBM Fix Central

Download the HSTS package for your Linux architecture from IBM Fix Central using an authorized IBMid. For Linux x86_64, IBM identifies the HSTS 4.4.8 build as 4.4.8.2589-linux-64-release.

For RPM-based systems, keep the downloaded HSTS RPM and IBM-provided PGP public key in a controlled installation directory. Confirm that you are installing the HSTS package, not HSTE or a client-only package.

mkdir -p /opt/install/aspera
cd /opt/install/aspera
ls -lh

6. Import the package-signing key and install HSTS

IBM's Linux installation procedure calls for importing the PGP key on Red Hat-family systems before installing the RPM. Use the actual file names downloaded from Fix Central.

rpm --import /opt/install/aspera/public-key.pgp
rpm -Uvh /opt/install/aspera/aspera-hsts-4.4.8*.rpm

The sudo package should be present on the Unix system because some Aspera applications use privileged operations.

rpm -q sudo
rpm -qa | grep -i aspera

After installation, verify that the standard Aspera directory exists and inspect the installed binaries.

ls -ld /opt/aspera
ls -l /opt/aspera/bin
/opt/aspera/bin/ascp -A

The final command is useful because ascp -A reports Aspera version and license information. If the product is not licensed yet, complete the next section before treating that output as the final validation.

7. Activate the license or entitlement

HSTS can be deployed with a perpetual license or with an IBM Aspera entitlement. The setup is different, so first identify which licensing model was purchased.

For a perpetual license, create /opt/aspera/etc/aspera-license and place the license text supplied for the environment in that file. IBM requires the license file permission to be 644.

vi /opt/aspera/etc/aspera-license
chmod 644 /opt/aspera/etc/aspera-license
/opt/aspera/bin/ascp -A

For a consumption-based entitlement, enable the Aspera License Entitlement Engine, register the customer and entitlement IDs, restart NodeD, and verify outbound connectivity to the IBM Aspera entitlement service.

/opt/aspera/bin/asalee-config.sh enable
/opt/aspera/bin/alee-admin register CUSTOMER_ID ENTITLEMENT_ID
systemctl restart asperanoded
curl -i https://api.ibmaspera.com/metering/ping

The metering connectivity check should return a successful HTTP response. If it cannot connect, validate DNS, outbound TCP 443, proxy requirements and enterprise egress controls before troubleshooting HSTS itself.

8. Move SSH to TCP 33001

Linux OpenSSH normally listens on TCP 22. IBM recommends using a nondefault SSH port for HSTS and documents TCP 33001 as the standard choice. Before changing it, confirm with the network team that TCP 33001 is allowed end to end and keep your existing administrative session open until the new port has been tested.

Edit /etc/ssh/sshd_config and set the required port and authentication methods. The exact authentication policy should follow your organization's SSH standard.

Port 33001
PubkeyAuthentication yes
PasswordAuthentication yes

Validate the SSH configuration before restarting the service.

sshd -t
systemctl restart sshd
systemctl status sshd
ss -lntp | grep 33001

From another system, validate that the new SSH port is reachable before closing the original management session.

ssh -p 33001 transfer_user@hsts.example.com

Once the new design is confirmed, TCP 22 can be removed from the HSTS transfer path if that matches the server-management standard. Do not lock yourself out by closing TCP 22 before validating the replacement management method.

9. Create a dedicated transfer user and docroot

A Linux account used for Aspera transfers should have access only to the data it needs. Avoid using root or an administrator account as the transfer identity.

useradd -m transfer_user
mkdir -p /data/aspera/transfer_user
chown -R transfer_user:transfer_user /data/aspera/transfer_user
chmod 750 /data/aspera/transfer_user

If password authentication is permitted for the initial lab test, set the password through the normal Linux process. For production, prefer your organization's approved SSH key or centralized authentication mechanism.

10. Configure the transfer user with asconfigurator

Most HSTS server settings are stored in /opt/aspera/etc/aspera.conf. You can edit the XML directly, but asconfigurator is safer because it validates the setting names and writes the configuration in the correct structure.

A good security baseline is to deny transfers globally and then explicitly allow the accounts that are meant to transfer.

/opt/aspera/bin/asconfigurator -x "set_node_data;authorization_transfer_in_value,deny"
/opt/aspera/bin/asconfigurator -x "set_node_data;authorization_transfer_out_value,deny"
/opt/aspera/bin/asconfigurator -x "set_node_data;read_allowed,false;write_allowed,false;dir_allowed,false"

Now configure the dedicated user's docroot and permissions.

/opt/aspera/bin/asconfigurator -x "set_user_data;user_name,transfer_user;absolute,/data/aspera/transfer_user"
/opt/aspera/bin/asconfigurator -x "set_user_data;user_name,transfer_user;authorization_transfer_in_value,allow"
/opt/aspera/bin/asconfigurator -x "set_user_data;user_name,transfer_user;authorization_transfer_out_value,allow"
/opt/aspera/bin/asconfigurator -x "set_user_data;user_name,transfer_user;read_allowed,true"
/opt/aspera/bin/asconfigurator -x "set_user_data;user_name,transfer_user;write_allowed,true"
/opt/aspera/bin/asconfigurator -x "set_user_data;user_name,transfer_user;dir_allowed,true"

If the transfer user will later be controlled by an Aspera web application such as Faspex or Shares, do not automatically reuse this allow-based example. Web-application transfer users are commonly configured for token authorization, which is a different security model.

11. Validate aspera.conf before restarting anything

The configuration file is XML, so a small manual-editing mistake can cause an unnecessary outage. Validate it before restarting services.

/opt/aspera/bin/asuserdata -v
/opt/aspera/bin/asuserdata -a
grep -n "transfer_user" /opt/aspera/etc/aspera.conf

The first command validates the configuration. The second displays the effective configuration data and is extremely useful when a setting appears correct in aspera.conf but the server is not behaving as expected.

12. Restart and verify the HSTS services

After changes to aspera.conf, restart the Aspera services that consume those settings. On current systemd-based Linux installations, the key services for this basic configuration are NodeD and Aspera Central.

systemctl restart asperanoded
systemctl restart asperacentral

systemctl status asperanoded
systemctl status asperacentral

If HTTP fallback has intentionally been configured, the separate asperahttpd service may also be relevant. HSTS 4.4.8 marks HTTP fallback components as deprecated, so it should not be enabled merely because an older installation guide included it.

13. Test TCP connectivity before testing FASP

Do not begin with a large file transfer. First prove the control path. From the client, test the server's TCP 33001 port.

nc -vz hsts.example.com 33001
ssh -p 33001 transfer_user@hsts.example.com

If this fails, the problem is in DNS, routing, the network firewall, the local firewall, SELinux policy or SSH configuration. There is no reason to tune FASP until the SSH control session works.

14. Run the first ascp transfer

Create a simple test file on the client and send it to the transfer user's docroot. The -P option selects the SSH TCP port. The example uses a fair policy and a modest target rate so that the first validation is controlled rather than a bandwidth stress test.

dd if=/dev/zero of=/tmp/aspera-test.bin bs=1M count=100

/opt/aspera/bin/ascp -P 33001 \
  --policy=fair \
  -l 100m \
  /tmp/aspera-test.bin \
  transfer_user@hsts.example.com:/

Because the user's docroot is /data/aspera/transfer_user, the remote / in the Aspera command refers to the root of that permitted transfer area, not the Linux filesystem root.

On the server, confirm that the file arrived with the expected ownership and size.

ls -lh /data/aspera/transfer_user
stat /data/aspera/transfer_user/aspera-test.bin

15. If SSH works but the transfer does not

This is the most useful troubleshooting split in an Aspera deployment. A successful SSH connection proves only the TCP control path. FASP still needs the UDP data path.

journalctl -u asperanoded --since "15 minutes ago"
journalctl -u asperacentral --since "15 minutes ago"
ss -lntp | grep 33001
firewall-cmd --list-all
/opt/aspera/bin/asuserdata -v

16. Optional: configure SSH public-key authentication

For production transfers, public-key authentication is normally preferable to embedding a Linux password in automation. Generate the key on the client, place only the public key in the transfer user's authorized_keys file on HSTS, and protect the directory and file permissions.

mkdir -p /home/transfer_user/.ssh
chown transfer_user:transfer_user /home/transfer_user/.ssh
chmod 700 /home/transfer_user/.ssh

vi /home/transfer_user/.ssh/authorized_keys
chown transfer_user:transfer_user /home/transfer_user/.ssh/authorized_keys
chmod 600 /home/transfer_user/.ssh/authorized_keys

Then test with the private key from the client.

/opt/aspera/bin/ascp -P 33001 \
  -i /secure/path/id_rsa \
  -l 100m \
  /tmp/aspera-test.bin \
  transfer_user@hsts.example.com:/

Do not copy the client's private key to the HSTS server. The server needs the public key only.

17. Optional: configure the Aspera Node API

The Aspera Node API is bundled with HSTS. It is required when another Aspera application or an automation platform needs to browse storage, create transfers, work with access keys or use Node API functions. It is not required simply to prove a direct ascp transfer.

The Node API uses HTTPS on TCP 9092 by default. First create or select a dedicated system user and configure its permitted transfer area. IBM's current Node API setup uses the token-authentication public key supplied with HSTS.

useradd -m node_transfer
mkdir -p /home/node_transfer/.ssh
cp /opt/aspera/var/aspera_tokenauth_id_rsa.pub \
  /home/node_transfer/.ssh/authorized_keys

chown -R node_transfer:node_transfer /home/node_transfer/.ssh
chmod 700 /home/node_transfer/.ssh
chmod 600 /home/node_transfer/.ssh/authorized_keys

Associate that system user with a Node API username and a strong password. Use a secret generated for your environment rather than a password copied into documentation.

/opt/aspera/bin/asnodeadmin -a \
  -u NODE_API_USER \
  -p 'STRONG_NODE_API_PASSWORD' \
  -x node_transfer

/opt/aspera/bin/asnodeadmin -l
systemctl restart asperanoded

Validate the local Node API endpoint before testing it through a load balancer or remote firewall.

curl -ik https://127.0.0.1:9092/ping

If the Node API will be consumed remotely, replace the default or temporary certificate with an enterprise-approved TLS certificate and restrict TCP 9092 to the required application networks.

18. Useful day-two validation commands

These are the commands I keep close during HSTS installation and handover because they quickly separate a Linux problem from an Aspera problem.

/opt/aspera/bin/ascp -A
/opt/aspera/bin/asuserdata -v
/opt/aspera/bin/asuserdata -a
/opt/aspera/bin/asnodeadmin -l

systemctl status asperanoded
systemctl status asperacentral

ss -lntp
firewall-cmd --list-all
df -h
free -h

19. Production checks I would not skip

20. What I would do differently

I would treat the HSTS installer as only one step in the deployment, not as the deployment itself. Before installing the RPM, I would have the TCP and UDP flows approved, decide whether the server uses a perpetual license or entitlement, decide how SSH authentication will work, define the transfer user's docroot, and decide whether Node API is actually required. That removes most of the back-and-forth that normally happens after the software is already installed.

When the first ascp transfer succeeds over TCP/UDP 33001, the next step is not to immediately push the link to maximum speed. Baseline the path first: confirm the effective user configuration, storage performance, packet loss, latency and firewall behavior, then tune the transfer policy and target rate for the actual network.

Contact

Working on something similar?

If one of these matches a problem in front of you, I am happy to talk it through.

Email me LinkedIn