FASP security: Aspera Connect transfer client authorized keys and aspshell

Edit online

Aspera Connect client uses "SSH bypass" keys. Those keys are delivered with the Aspera Connect client. They allow the client to start a FASP session without requiring a password, while security is implemented on protocol level with a security "token". The associated public keys are enhanced with OpenSSH specific stanza that forces the use of a compatible secure environment: aspshell and token authorization. This article explains how it works.

Important: Depending on the version of Aspera client you are using, the client may only support DSA keys for SSH authentication, or include a DSA key in addition to the RSA key. DSA keys are deprecated and the transfer servers won't be supporting this type of keys in the future.

Keys on Aspera Connect client

Aspera Connect client comes with the following key (SSH bypass keys):

  1. aspera_tokenauth_id_rsa

Item 1 is a RSA private key, protected by a passphrase.

When Aspera Connect client starts a transfer, it provides the key on ascp command line (-i), and the passphrase with the ASPERA_SCP_PASS env var.

Keys on Aspera High-Speed Transfer Server (HSTS)

HSTS includes an SSH private key in <installdir>/var:

  • aspera_tokenauth_id_rsa (RSA,newer)

This key is used by asperanoded to start node-to-node transfers, and it is passphrase-protected.

The public key is provided in the following file:

  • aspera_tokenauth_id_rsa.pub

The file uses the OpenSSH format for authorized_keys. This format can be consulted in the man page of sshd(8) in section "AUTHORIZED_KEYS FILE FORMAT".

When configuring a "transfer user" (that is, a user known by the SSH daemon on the server) for use with web applications (Faspex and others), the content of aspera_tokenauth_id_rsa.pub must be added to the transfer user's authorized_keys file (see the IBM Aspera Connect Connect User Guide). This file contains:

command="/bin/aspshell -t",no-agent-forwarding,no-port-forwarding,no-X11-forwarding,no-pty ssh-dss AA<content cut>Ko= Aspera public access
command="/bin/aspshell -t",no-agent-forwarding,no-port-forwarding,no-X11-forwarding,no-pty ssh-rsa AA<content cut>zQ== Aspera public access

Security considerations

Note that some additional options are added before the actual public key. Those keys (public and private) are "well known": private keys are directly delivered with the Aspera Connect client.

The security of the connection using SSH for FASP in web applications using those keys relies on three items:
  • SSH shall allow transfers only, not execution of any other commands: This is enforced by setting the SHELL of the transfer user to "/bin/aspshell".
  • The transfer shall be allowed by an authentication token.

    This is enforced by setting the parameters "authorization_transfer_in_value" and "authorization_transfer_out_value" to "token" in aspera.conf.

  • It shall not be possible to "browse" using FASP (that is, using ascmd).

    This is enforced by using aspshell in "loose" mode (see below, option "-r").

Moreover, the sshd daemon shall be configured to disallow some features, such as port forwarding at least for the transfer users.

On Linux, the administrator shall take care of setting the shell appropriately. On Windows, the asconfigurator command will set the shell to aspshell if the docroot of the user is not empty. In both cases, this can be checked in the "passwd" file.

The aspshell provides a loose mode (also know as a restricted mode); this is enforced by calling it with option "-r". For ease of configuration, aspshell can also be called with the name "aspshell-r" which is equivalent to calling with the -r option.

The aspshell is a shell that allows execution of only some commands. For instance, on Linux, those commands can be listed like this:
# strings /bin/aspshell|grep -E '^!?as[cy][^i][a-z0-9]*( [^,]+)?$'
ascp -S. -V1
ascp4 -S.
async -q -S -s-
!ascmd
!ascmd -V2
ascp --no-mgmt-port-files -M %d -S. -V1 %1s

The lines starting with "!" are not allowed in loose mode. The first line allows legacy ascp transfers (server side). The second line allows ascp4 transfers. The third line allows the use of async. The ascmd lines are used by Desktop client GUI, Console, and Orchestrator to list files under the docroot (and other operations). The last line is the command used by async for file transfers.

Authentication token use is enforced by setting the transfer's users parameters in aspera.conf with commands like (see the manuals):
asconfigurator -x "set_user_data;user_name,faspex;authorization_transfer_in_value,token;authorization_transfer_out_value,token"

If those configurations are not properly made, then the server is at risk of either getting malicious SSH connections in a standard shell (bash), or having files browsable and downloadable without using the web applications authorization.

Enforcement directly in authorized_keys

It was noted that the lines added to the transfer user's authorized_keys files for OpenSSH begin with:
command="/bin/aspshell -t",no-agent-forwarding,no-port-forwarding,no-X11-forwarding,no-pty

This actually enforces most of the items listed previously: Instead of executing the command provided in the SSH connection (normally "ascp -S. -V1", but a malicious user may try to execute another command), OpenSSH will execute "/bin/aspshell -t" and place the actual command in an envvar (SSH_ORIGINAL_COMMAND). The "-t" option will do the following:

  • Enforce the "loose mode" (restricted mode, no ascmd)
  • Set an envvar: ASPERA_AUTH_TOKEN=TOKEN
  • Validate that the command in SSH_ORIGINAL_COMMAND is allowed (ascp, same as regular aspshell invocation)

When ascp is invoked, if the envvar ASPERA_AUTH_TOKEN is set to TOKEN, it will override the values of the parameters authorization_transfer_in_value and authorization_transfer_out_value to "token" (even if those values were set to "allow" in aspera.conf).

So, even if the basic security configuration was overlooked by the administrator (aspshell-r and token auth), those parameters in the authorized_keys file will effectively enforce the security.

Note that this is specific to OpenSSH, and care shall be taken with other SSH servers (bitvise and others)