Cyberduck Mountain Duck CLI

#10620 closed feature (fixed)

Read session token credentials from AWS CLI configuration file

Reported by: vwalveranta Owned by: dkocher
Priority: normal Milestone: 7.0
Component: s3 Version: 6.9.3
Severity: normal Keywords: MFA session token
Cc: Architecture:


When MFA is required/enforced in order to use for a given profile, it cannot be used with Cyberduck currently because Cyberduck doesn't allow the entry of the session token along with the standard AWS credentials. This is separate from the deletion token that can be set on S3 buckets, and when configured and enforced, it doesn't allow any access with given access key ID / secret access key unless a user is in MFA session (and so that the session token is also provided). When an MFA session is initialized, AWS provides a new access key ID and a new secret access key (they are separate from the credentials of the profile the MFA session was started for) in addition to the session token. These credentials are only valid for the validity period of the session.

This is supported, for example, by Cloudberry Explorer. I have created a set of scripts to manage the MFA sessions on the command line as my employer is moving to MFA enforcement also on the command line (with the enforcement enabled any tool that utilizes the access keys won't work unless it allows also the entry of the session token). The utility scripts and their documentation can be found at the following URL:

Change History (13)

comment:1 Changed on Feb 17, 2019 at 9:26:03 AM by dkocher

  • Component changed from core to s3
  • Owner set to dkocher
  • Version set to 6.9.3

comment:2 Changed on Feb 17, 2019 at 9:45:13 AM by dkocher

Not sure if I am correct but I assume we support this Connecting using AssumeRole from AWS Security Token Service (STS).

comment:3 Changed on Feb 17, 2019 at 8:51:49 PM by vwalveranta

Yes, I believe STS token feature is available for assuming roles i.e., to create a role session.

However, there is no facility in Cyberduck at the moment to enter a baseprofile MFA session token.

A baseprofile session is created like so:

aws --profile "some_baseprofile" sts get-session-token --serial-number "mfa_arn_associated_with_the_baseprofile" --duration "3600" --token-code "current_code_from_generator" --output "json"
  • some_baseprofile: refers to the label name of a profile in ~/.aws/credentials or in ~/.aws/config
  • mfa_arn_associated_with_the_baseprofile: refers to the virtual MFA attached to the profile; this is the same vMFA that can be attached to the profile via the web console.
  • duration: can be enforced by the MFA enforcement policy (see example in my repo). Otherwise, it's the AWS default.
  • current_code_from_generator: the current generated token from the Google Authenticator -compatible code generator.

Creating an MFA session as described above is basically analogous to entering an MFA code when logging in to AWS console, except that the awscli command spits out the MFA session credentials that with the console the web browser automatically caches. On CLI one has to either refer to the MFA profile with AWS_PROFILE evvar, or export the session credentials to the environment. With client apps like Cloudberry Explorer or Cyberduck, those MFA session credentials need to be entered into the connection profile.

While a role can be used to bestow an IAM user additional privileges by assuming one, the baseprofile MFA can be used to block access to the IAM user altogether unless the user is in an active MFA session. In our enforcement policy, we allow a user (who has this policy) to configure their virtual MFA device, update their password, and create a new MFA session.. and nothing else. Once they have started an MFA session, then they have their regularly assigned privileges for the lasting of the session. During this time they can also assume roles, thus entering into a role session. Both the baseprofile MFA sessions and the role sessions create a wholly new set of credentials (i.e. separate from the baseprofile/source profile the session was created for): a new aws_access_key_id, aws_secret_access_key, and aws_session_token. Cyberduck currently provides a way to enter the session token to assume a session, but not to use a baseprofile MFA. I'd recommend just adding an additional field ("Session Token") into the connection profile window for the S3 connections. If the field has content, then inject it into the request as aws_session_token. The credentials for MFA and non-MFA are of the same format except for the MFA sessions the session token is present (and the access key id begins "ASIA.." instead of "AKIA..").

Last edited on Feb 17, 2019 at 10:00:17 PM by vwalveranta (previous) (diff)

comment:4 Changed on Feb 17, 2019 at 8:55:22 PM by vwalveranta

N.B.: If you implement this feature, you might find my utility script useful for creating sessions to test with as the awscli API commands for creating and managing sessions are rather cumbersome. For more info see my repo at

Last edited on Feb 17, 2019 at 9:40:54 PM by vwalveranta (previous) (diff)

comment:5 Changed on Feb 17, 2019 at 9:06:42 PM by vwalveranta

One more thing :-)

How are the baseprofile MFA sessions actually applicable to Cyberduck? Basically, if you have a set of AWS credentials, an aws_access_key_id, and aws_secret_access_key, but the MFA is set to be required for that IAM user, those credentials are no good for anything (such as for accessing the S3 buckets the user has privileges for) unless they provide the MFA session credentials instead of the corresponding baseprofile credentials.

The process would then be like this:

  1. In the aws CLI, the user starts an MFA session for their IAM account. AWS provides a new aws_access_key_id, aws_secret_access_key, and aws_session_token. My script can make this less painful.
  2. The user opens a client (currently Cloudberry Explorer or, hopefully, Cyberduck in the future :-) and enters the session credentials (including the aws_session_token) into the connection profile.
  3. The user connects normally to the S3 buckets their IAM account has the privileges for.
  4. Once the session ends, the access ends (and the user has to create a new MFA session in the CLI and update the session credentials in the connection profile to reconnect).
Last edited on Feb 17, 2019 at 9:47:05 PM by vwalveranta (previous) (diff)

comment:6 Changed on Feb 28, 2019 at 10:28:48 PM by dkocher

  • Milestone set to 7.0
  • Status changed from new to assigned

comment:7 Changed on Feb 28, 2019 at 10:41:41 PM by dkocher

Can you confirm that you can successfully connect if you

Credentials should be read from the base profile configuration including the session token and the connection should succeed.

Last edited on Mar 1, 2019 at 8:26:12 AM by dkocher (previous) (diff)

comment:8 Changed on Mar 7, 2019 at 10:00:38 PM by vwalveranta


Confirmed! This form of implementation is a great approach as this way the session credentials don't need to be coped into the connection profile every time. Well done!

I would augment the documentation at under the subsection: "Read credentials from ~/.aws/credentials" to point out that if an AWS MFA session credentials (not only a role session credentials) are persisted in ~/.aws/credentials, that MFA or role session profile can be referred to directly, e.g. myprofile-mfasession instead of myprofile (the -mfasession and -rolessession postfixes are what my script, mentioned above, persists the MFA sessions and MFA-enabled role session credentials as, but users can, of course, name the MFA session profiles whichever way they like if they acquire the MFA/role session manually with awscli sts get-session-token command instead of using my utility script).

comment:9 Changed on Mar 9, 2019 at 9:22:15 PM by dkocher

  • Milestone changed from 7.0 to 6.9.5
  • Resolution set to fixed
  • Status changed from assigned to closed

Updated documentation available in Connecting using credentials in ~/.aws/credentials with additional profile in r46545.

comment:10 follow-up: Changed on Mar 10, 2019 at 12:28:35 AM by vwalveranta


Thanks for the reference! :-)

One typo fix: " third parties to facility managing credentials" -> " third parties to facilitate managing credentials".

Last edited on Mar 10, 2019 at 8:39:44 AM by dkocher (previous) (diff)

comment:11 in reply to: ↑ 10 Changed on Mar 10, 2019 at 8:39:53 AM by dkocher

Replying to vwalveranta:


Thanks for the reference! :-)

One typo fix: " third parties to facility managing credentials" -> " third parties to facilitate managing credentials".


comment:12 Changed on Mar 10, 2019 at 8:40:33 AM by dkocher

  • Summary changed from Add AWS session token field for S3 connections to Read session token credentials from AWS CLI configuration file

comment:13 Changed on Jun 4, 2019 at 2:20:54 PM by dkocher

  • Milestone changed from 6.9.5 to 7.0

Ticket retargeted after milestone deleted

Note: See TracTickets for help on using tickets.