Quick start guide to setting up an Aspera Node API User on Linux

Description

The Node API is part of Enterprise Server and provides a RESTful interface for remote file operations and transfer initiations. Aspera web applications authenticate to a remote node service (a remote Enterprise Server) using a Node API username and password. Use the following instructions to set up a Node API user on Windows.

Assumptions

The following are some assumptions made to simplify these instructions

  1. System is CentOS or RedHat based;
  2. Firewall will be disabled. Note below on the ramifications of this;
  3. System user called xfer will be created -- this is the user on the OS that transfers happen as;
  4. Node user called node_user will be created -- this is the Node API user Shares/Faspex/your app uses;
  5. Hostname used in example for the system is example.com -- this is normally a FQDN or IP address that is accessible to transfer participants and MUST be changed;
  6. The docroot is /data and we have to create it so that the xfer user can access it;
  7. System has the correct Aspera software -- minimum of P2P, normally Enterprise Server or Connect Server depending on use case;
  8. System has the correct license for the installed product.

A Note on Passwords and Keys

These instructions need to make some assumptions on passwords and keys. To prevent an insecure situation where a simple copy & paste results in multiple systems sharing the same credentials, the steps below use a few methods for generating random keys and passwords. Your own passwords and keys can be used in place of these steps, but it is not recommended. Here is a description of the methods used and some alternatives:

  • uuidgen: This is a tool that creates unique identifiers per ITU-T Rec. X.667 | ISO/IEC 9834-8 | RFC 4122 that are 128bit. The output may look like 9bdffe0a-a644-43a8-9035-fa00135fb8ad
  • /dev/urandom to base64: /dev/urandom generated pseudo-random data that is not necessarily human readable. base64 is used to make it usable. The full command is dd if=/dev/urandom bs=18 count=1 2> /dev/null | base64
  • uuidgen to SHA256: Just another use of UUID. Using openssl to convert string to an SHA format, the data is still readable, but now 256bits. The full command is uuidgen | openssl sha256 | cut -d ' ' -f2

The above can be combined and performed in various permutations. They can be truncated, etc, to make them more usable.

For the purpose of this quick-start guide, the Node API user's password will be generated using the /dev/urandom to base64 method, while the token key in aspera.conf uses uuidgen.

Instructions

  1. If not done already, enable port 33001 for SSH. The commands below will keep 22 open, but this can be removed. It is recommended that external access to port 22 is disabled either at the network or host level.
     perl -p -i -e 's/^#Port 22/Port 22\nPort 33001/' /etc/ssh/sshd_config
     service sshd restart
    
  2. SELinux should be disabled. While Aspera can work inside SELinux, it is generally not needed and little unexpected things can happen.
     setenforce 0
     perl -p -i -e 's/=enforcing/=disabled/' /etc/selinux/config
    
  3. The following steps disable the Linux firewall. This is a convenience step. It is recommended that a firewall is used, either at the network or host level, or both. In place of these steps, the ports outlined in the Admin guide should be allowed, and all others blocked.
     chkconfig --levels 2345 ip6tables off
     chkconfig --levels 2345 iptables off
     service iptables stop
     service ip6tables stop
    
  4. The asconfigurator tool is used to edit aspera.conf. This tool is documented in a KB Article. The aspera.conf changes will set a token key with uuidgen, set the default transfer rate to 100Mbps, enable the Central service Persistent Store and set the server to use example.com in transfer requests. It is IMPORTANT to note: while most of this document can be simple copied and pasted into a terminal, the server_name has to be set correctly to something other than example.com
     asconfigurator -x "set_node_data;token_encryption_key,`uuidgen`"
     asconfigurator -x "set_node_data;transfer_out_bandwidth_flow_target_rate_default,100000"
     asconfigurator -x "set_node_data;transfer_in_bandwidth_flow_target_rate_default,100000"
     asconfigurator -x "set_central_server_data;persistent_store,enable"
     asconfigurator -x "set_server_data;server_name,example.com"
    
  5. A transfer user needs to be created. This can be a pre-existing user, but for this guide, a user called xfer will be created. The shell is set to aspshell to prevent interactive logins.
     useradd -s /bin/aspshell xfer
    
  6. This user now needs to use the SSH public key that matches the private key used by the Connect plugin. This involves placing the key in the authorized_keys file and making sure it is secure and readable by the user.
     mkdir /home/xfer/.ssh
     cp /opt/aspera/var/aspera_id_dsa.pub /home/xfer/.ssh/authorized_keys
     chmod 700 /home/xfer/.ssh
     chmod 600 /home/xfer/.ssh/authorized_keys 
     chown -R xfer:xfer /home/xfer/.ssh
    
  7. Create the /data location and make it owned by the xfer user.
     mkdir /data
     chown xfer:xfer /data
    
  8. Change the aspera.conf to reflect this docroot. Also, set the authorization to use tokens rather than a wide-open allow.
     asconfigurator -x "set_user_data;user_name,xfer;authorization_transfer_out_value,token"
     asconfigurator -x "set_user_data;user_name,xfer;authorization_transfer_in_value,token"
     asconfigurator -x "set_user_data;user_name,xfer;absolute,/data"
    
  9. We now create a password that will be used by the Node API user. It is saved in a variable so we can print it to the screen (so it can be copied and used in Shares, etc) and passed into the config.
     NODE_PASS=`dd if=/dev/urandom bs=18 count=1 2> /dev/null | base64`
     echo ${NODE_PASS}
    
  10. Now the password is used, along with the transfer user xfer, to create the Node API user node_user
     /opt/aspera/bin/asnodeadmin -a -x xfer -u node_user -p ${NODE_PASS}
    
  11. The asperacentral service needs to be restarted because of the Persistent Store being enabled. asperanoded service needs to be restarted because of all the changes to the config (although it may have reloaded already, this is just for good measure).
     service asperacentral restart
     service asperanoded restart
    
Have more questions? Submit a request

2 Comments

  • Avatar
    Wendy Meng

    Hi John,

    Does the node you mentioned in this page have the same meaning with the node mentioned on below page? 

    https://developer.asperasoft.com/web-advance/node

    Thanks

    -Wendy from HBO

     

     

  • Avatar
    Andrea Campos

    Hi Wendy,

    Yes, the Node user in this article refers to Node API users. That ADN page talks about how to access Node API endpoints via REST, and as you can see it also mentions needing to create a Node API user.

Please sign in to leave a comment.
Powered by Zendesk