Running async as root when you can't authenticate as root



The async binary offers command-line flags for preserving user ID and group ID on the destination host (-u and -j, respectively). For these features to work, async and ascp must run as root on the destination, because only root has privileges to create a file or directory as another UID/GID.

However, some organizations have security policies which prohibit authenticating as root over the network. This article presents a method of authenticating as an ordinary user, and using sudo to elevate privileges. The async binary uses ascp for the FASP transfers, so our solution must include ascp as well.



The client-side async command contains a username that we authenticate to the server. In our example we'll use asp1. On the server, async and ascp are invoked by an ssh process running as asp1. Our method modifies the $PATH variable of user asp1 so that, instead of calling the normal async and ascp binaries, ssh invokes scripts that call async and ascp via sudo

This method has the advantage of applying only to user asp1 (other users would run async or ascp normally). Permissions can be set on the scripts directory such that only user asp1 can execute them.



Perform steps 1-7 on the destination server.

1) Create user & group asp1

# groupadd asp1
# id asp1
# useradd -c "Async transfer user" -s /bin/bash -g 1002 -d /home/asp1 -m asp1


Use the id command to find the GID of the new group asp1 (such as 1002), which you will supply to the useradd command's -g flag.

We recommend that you setup a designated account, such as asp1. Only user asp1 will execute async via sudo. Other users who authenticate to the server will run async in the standard manner.


2) Enable user asp1 to run async and ascp as root

a. Edit the sudo database

# visudo


b. If necessary, comment out the requiretty line

#Defaults requiretty
We won't be using a tty to call sudo, so we must turn off the requiretty feature. This line may already be commented out.

c. Add the following line to the end of the file

asp1 ALL=NOPASSWD: /opt/aspera/bin/async, /opt/aspera/bin/ascp
  • ALL here refers to "all hosts." If this sudoers file is consulted by other hosts, you should replace the ALL keyword with an alias restricting the scope to the localhost.
  • sudo normally asks for a password, so the NOPASSWD keyword bypasses this.

3) Prepare script directory

# mkdir /opt/aspera/sudo
You may choose another name than sudo, but the location must be inside the /opt/aspera tree.

4) Create async script

a. Create a file named /opt/aspera/sudo/async that contains the following content:

sudo /opt/aspera/bin/async $*


5) Create ascp script

a. Create a file named /opt/aspera/sudo/ascp that contains the following content:

sudo /opt/aspera/bin/ascp $*


6) Set permissions on the /opt/aspera/sudo tree

# chown -R asp1:asp1 /opt/aspera/sudo
# chmod 100 /opt/aspera/sudo
# chmod 500 /opt/aspera/sudo/async
# chmod 500 /opt/aspera/sudo/ascp 
With these permissions, only user asp1 will be able to execute the scripts.


7) Edit user asp1's .bashrc file

a. Edit /home/asp1/.bashrc and add these lines:

export PATH


If there is already a PATH statement in the .bashrc file, modify the line accordingly. The important thing is for /opt/aspera/sudo to appear in the path before /usr/bin.


8) Now we are ready to try async from the client. 

$ async -N test1 -b /path/to/local/syncdb -B /path/to/remote/syncdb -utj -d /path/to/local/src -r asp1@server:/path/to/remote/dest -w asp1_passwd -K push -P 33001 --create-dir


What you should see on the server:

  • new directory /path/to/remote/dest should have files with their proper user groups
  • sudo log entries in /var/log/secure noting that user asp1 executed both /opt/aspera/bin/async and /opt/aspera/bin/ascp




1. The sudo error "sorry, you must have a tty to run sudo" indicates that you need to disable requiretty. See step 2b.

2. The sudo error "no tty present and no askpass program specified" indicates that you need to add the NOPASSWD keyword to the sudoers file. See step 2c.


Have more questions? Submit a request


Article is closed for comments.
Powered by Zendesk