Rclone YubiKey Integration Progress

The well-known rclone tool for accessing and synchronizing cloud-based storage can have its configuration encrypted using a symmetric cipher with password-derived key. However some elaborate work is needed to provide a higher protection of the configuration secrets - for example using the YubiKey 5 security token. There is alredy some development under way to streamline such usage.

As a part of one of our current projects our task is to help large teams collaborating on scientific research securely share the experimental data using cloud storage services - mainly using the Amazon S3 protocol. Although the storage clusters in question are backed by Ceph and deployed on premises, still care needs to be taken when working with potentially sensitive data like genomic seqeuences and personal health information in medical research.

Each data set is created, accessed and analyzed by one research team consisting of multiple researchers from various institutions. The good thing is that rclone supports an encrypted overlay over any supported cloud storage backend with static symmetric key known only by the members of the team. And although there is an ongoing discussion about better key management, this is the current state of affairs and no advanced features like multiple keys management (including revocation) exist, the features available offer a decent data confidentiality assurance if the key material is handled with care.

Each user has their configuration in the rclone.conf file which can be encrypted using a symmetric cipher and a password-derived key. That means each time the configuration is edited or used, the configuration password must be provided. To help with integration with other security tools like password managers or hardware security tokens the ''--password-command'' command-line option is provided that already allows for decent flexibility in the current release.

Let us put aside the question how to setup the environment so the configuration is protected by externally provided password and assume it has already been setup. It is then possible to require YubiKey presence and user confirmation of any configuration access using the token plugged in the USB port. For the three major platforms - GNU/Linux, MacOS and even the historical Microsoft Windows - it is actually pretty straightforward to set it up.

This approach uses the ykchalresp binary from the YubiKey Personalization Tool suite. Firstly the token's second slot is confiugred with the proper challenge-response style schema that will be used for deriving the " password" from the secondary secret key:

ykpersonalize -2 -ochal-resp -ochal-hmac -ohmac-lt64

A brief explanation of the command-line options is probably appropriate:

• -ochal-resp - configure the slot for usage with challenge-response mode,
• -ochal-hmac - make it generate HMAC-SHA1 responses,
• -ohmac-lt64 - calculate HMAC on less than 64 bytes input.

And with the token configured, something as simple as the following can be used:

ykchalresp -2 -N rclone-config >/dev/null 2>&1

In order to use it as password source for the rclone configuration, it has to be passed as proper command-line argument:

rclone --password-command "ykchalresp -2 rclone-config" --config rclone.conf ls some-remote:

With a bit of scripting, it is relatively easy to make this process user-friendly. Firstly we create a shell function to detect whether the token is present:

# Returns true if some yubikey is connected to the computer
yubikey_present() {
    if ykinfo -v >/dev/null 2>&1 ; then
        return 0
    else
        return 1
    fi
}

Secondly we define a function that waits for it and show a nice dialog that allows us to cancel the operation using the Zenity dialog framework:

# Waits for YubiKey to be inserted, allows the user to cancel the operation
wait_for_yubikey() {
    zenity --info \
           --text="Please insert your YubiKey..." \
           --ok-label="Cancel" \
           --title="rclone configuration" &
    zid=$!
    while ! yubikey_present ; do
        if ! ps -p $zid >/dev/null 2>&1 ; then
            exit 1
        fi
        sleep 0.1
    done
    kill -TERM $zid
}

Then the overall process of waiting for the token and producing the secret password upon user confirmation looks like:

# Do not start ykchalresp before there is a YubiKey present
if ! yubikey_present ; then
    wait_for_yubikey
fi

# Spawn a dialog to cancel the request and request a response to given
# challenge
zenity --info \
       --text="Please tap the YubiKey button..." \
       --ok-label="Cancel" \
       --title="rclone configuration" &
zid=$!
ykchalresp -2 $CHALLENGE &
yid=$!
while ps -p $yid >/dev/null 2>&1 ; do
    if ! ps -p $zid >/dev/null 2>&1 ; then
        kill -TERM $yid
        ykchalresp -2 -N $CHALLENGE >/dev/null 2>&1
        exit 1
    fi
    sleep 0.1
done
kill -TERM $zid

It is worth noting that there are a few issues with process management that such script needs to handle - other options than those shown exist. It is also important to understand the ykchalresp -2 -N $CHALLENGE >/dev/null 2>&1 command when cancelling the request as the YubiKey and related software does not implement canceling an ongoing challenge-response request. The good news is that re-issuing the challenge-response command with the -N option cancels the request if it needs to wait for user confirmation - which it does.

Assuming the script is stored in linux-yubikey-password-command.sh, the usage is straightforward:

rclone --password-command linux-yubikey-password-command.sh --config rclone.conf ls some-remote:

A similar approach works on Microsoft Windows and MacOS, the actual scripts will be - of course - different.

The only problem that remains is the inability to easily setup such password-protected configuration. The current stable version of rclone does not honor the --password-command command-line option for setting up configuration password and always uses the terminal-based password query.

This is about to change in the very next release. With the support of the team at Storage Department department of CESNET the maintainer of rclone Nick Craig-Wood has already implemented the required functionality reported in the GitHub Issue#7859 and in a few weeks we can expect it in the stable version.

We will definitely publish a subsequent article on how to set this configuration up when the new version is released.

With the hope this was an interesting reading, see you next time!