Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
cyberduck opened this issue Apr 16, 2021 · 1 comment
Labels
bug s3 AWS S3 Protocol Implementation worksforme

Comments

@cyberduck
Copy link
Collaborator

655a51a created the issue

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: https://github.com/99designs/aws-vault

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.

@cyberduck
Copy link
Collaborator Author

@dkocher commented

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.

@iterate-ch iterate-ch locked as resolved and limited conversation to collaborators Nov 27, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug s3 AWS S3 Protocol Implementation worksforme
Projects
None yet
Development

No branches or pull requests

1 participant