I tried both, us-gov-west-1 fails (using the server) and us-west-1 works (using the s3. server). Yes I have in my credentials file us-gov-west-1 instead of us-west-1. Any ideas?ĭid you try us-gov-west-1 as a region in your credentials file? I guess the issue is that it tries to connect to the wrong STS endpoing which is built from that string. I'm using as the 'Server' and cyberduck gets into a loop where it says 'Authenticating as publish_profile' followed by 'Login failed'. This credentials file configuration (previously mentioned by dt001) works perfectly with commercial S3 regions (server: s3., region: us-west-1) but not with AWS GovCloud (server:, region: us-gov-west-1). When configuring AWS CLI for this, I'd have an entry for the master account, and then one entry for each assumed role, such as: I notice a few people are suggesting entry of the security token - but isn't that short-lived? Don't see how that's a stable configuration solution. It does support roles from an EC2 instance, so I think it should be very easy to support from my own OSX laptop? I was thinking of just running a local proxy for 169.254.169.254 to fake the fact I am not running on EC2, but it seemed like overkill. But unfortunately cyberduck only supports IAM users and not roles. I would like to use cyberduck instead as it can thread nicely.

If you set these 3 things in your environment, you can use tools like awscli etc from command line. This means to connect to S3, it needs more than just SecretKey and AccessKey, it also need SecurityToken or SessionToken which is an extremely large string.

I am using amazon AssumeRole function to assume a role that can access an S3 bucket.

Aws cyberduck