Cyberduck Mountain Duck CLI

#11649 closed defect (worksforme)

Can't reorder new S3 session, some previously working S3 sessions are broken, may be related to aws-vault

Reported by: mjcsb Owned by:
Priority: normal Milestone:
Component: s3 Version: 7.8.5
Severity: blocker Keywords: S3
Cc: Architecture:


I haven't used this in a few months, just opened and tried to create a new S3 session, I know the access/secret key works, but it refuses to list. The error I'm getting is:

Listing directory / failed. Access Denied. Please contact your web hosting service provider for assistance.

I then tried an existing session, and I know one that worked before no longer works, despite no changes to the access key pair.

I then tried to move the new session from the bottom of perhaps 50 existing sessions up to the top, and I could not move the session, it kept reverting to the bottom. I tried moving to the middle, reverted to the bottom.

I opened this ticket to report, and while I started to write it, I realized that the two affected sessions (new + existing) are both sessions where I have commented out the credentials in ~/.aws/credentials, and have added an mfa_serial= property in the ~/.aws/config. I am in the process of testing prior to switching to the use of the aws-vault method of securely storing the AWS credentials in the macOS keychain, so these credentials are no longer insecurely stored in plain text in the non-encrypted ~/.aws/credentials file. Please see more about this project here:

This method is used in the Terraform community to run Terraform code via the CLI with MFA auth using STS temp tokens, as a more secure method of using the CLI.

I thought Cyberduck was saving and using the access/secret key for sessions in it's own database? Why ask for them if instead it is referencing the ~/.aws/* files - when if that's the case, you should just collect the profile to use to lookup the config and credentials file values?

It seems like there is some hidden / non-documented behavior where the ~/.aws config files are referenced, despite the fact your UI asks me specifically for these values, implying there is no such link and you store the values internally and separately from the AWS CLI configuration.

So, if I switch to using this tool, and it breaks what I thought was independent use of CyberDuck as an S3 browser, this would make CyberDuck useless to me, so I think this is a pretty severe bug.

I think you either need to: A: Accept a secret/access key, store that internal to your app config, and do not reference the AWS CLI configuration information stored under ~/.aws/* - this is a separate tool, why would you depend on it in this use-case??

B: As an alternative to A, allow the user to specify a profile, and by such a choice, this means you would lookup the information stored in the ~/.aws/* config used by AWS CLI, and you would NOT store the access/secret key in your own config, as that would be redundant.

C: Better yet, figure out some way to work with aws-vault, as this seems to be an increasingly used tool in the infrastructure-as-code community with Terraform and AWS.

What you have there now, is the worst of all options, in that I'm specifying the access/secret key pair to avoid changes I'm making to increase security on use of the AWS CLI, which I thought would be independent of a separate S3 browser tool, not a profile, yet you're still depending on this separate tool's config, even though you're double-collecting the same credential information.

I'd bet if your engineers contacted this open source project, you could work together to find a way to use the same aws-vault additional keystone in the MacOS KeyChain to lookup the values by name, or use their method of using STS to create temp tokens, increasing your own security and compatibility.

I really like your tool for S3 access! Please don't let my use of aws-vault to improve security in AWS CLI and/or Terraform and/or CloudFormation use via CLI commands break what SHOULD be a completely separate S3 browser tool.

I don't know what you did with recent updates, but it seems multiple issues are now broken.

Change History (2)

comment:1 Changed on May 10, 2021 at 1:07:10 PM by dkocher

  • Resolution set to worksforme
  • Status changed from new to closed

If you configure a bookmark with a username set to a matching profile name in ~/.aws/credentials we read access keys from there. See also Connecting using credentials in ~/.aws/credentials.

comment:2 Changed on May 10, 2021 at 1:07:16 PM by dkocher

  • Component changed from core to s3
Note: See TracTickets for help on using tickets.