Cyberduck Mountain Duck CLI

#8880 closed feature (fixed)

Authentication using AWS AssumeRole and GetSessionToken with AWS STS

Reported by: tigris Owned by: dkocher
Priority: high Milestone: 6.7.0
Component: s3 Version: 4.7
Severity: normal Keywords: s3 iam sts mfa
Cc: Architecture: Intel
Platform: Mac OS X 10.10

Description (last modified by dkocher)

I am using amazon AssumeRole function to assume a role that can access an S3 bucket. 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.

If you set these 3 things in your environment, you can use tools like awscli etc from command line. I would like to use cyberduck instead as it can thread nicely. But unfortunately cyberduck only supports IAM users and not roles.

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.

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. 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:

[profile master]
region = us-east-1
output = json

[profile security]
role_arn = arn:aws:iam::999999999999:role/MyAccessRole
source_profile = master
region=eu-west-1
output=json

I think you need a way to collect and use this information, mainly the role_arn and reference to the source_profile.

Change History (63)

comment:1 Changed on Jun 16, 2015 at 9:04:57 AM by dkocher

Referencing Support S3 authentication via IAM Role credentials #8610.

comment:2 Changed on Jun 16, 2015 at 9:08:29 AM by dkocher

  • Component changed from core to s3
  • Owner set to dkocher
  • Summary changed from S3 via an amazon assumed role to Authentication using AWS AssumeRole and GetSessionToken

comment:3 follow-up: Changed on Sep 10, 2015 at 10:40:17 AM by limitusus

  • Keywords sts added

I also would like this fixed. STS provides safer access privileges.

Does it take time to fix?

comment:4 in reply to: ↑ 3 Changed on Sep 10, 2015 at 2:31:45 PM by dkocher

Replying to limitusus:

I also would like this fixed. STS provides safer access privileges.

AWS Security Token Service (STS)

comment:5 Changed on Sep 10, 2015 at 2:36:48 PM by dkocher

Can you post the transcript from the log drawer (⌘-L) for the authentication failure that we get when trying to authenticate with the AccessKeyId and SecretAccessKey only with the token missing.

comment:6 Changed on Sep 10, 2015 at 2:41:44 PM by dkocher

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

comment:7 Changed on Sep 10, 2015 at 3:41:12 PM by limitusus

Sure. I set ACCESS_KEY_ID as user name and SECRET_ACCESS_KEY as password, without setting SESSION_TOKEN, and got the below transcript log. Please check it out.

GET / HTTP/1.1
Date: Thu, 10 Sep 2015 15:34:51 GMT
x-amz-request-payer: requester
Authorization: AWS ASIAJMHJ3CDT6TZFE5VQ:n6tV+L8WNQJPzE8U9bLJupZwEgg=
Host: s3.amazonaws.com:443
Connection: Keep-Alive
User-Agent: Cyberduck/4.7.2.18004 (Mac OS X/10.10.5) (x86_64)
HTTP/1.1 403 Forbidden
x-amz-request-id: 18855270603EBB20
x-amz-id-2: MLFktIVbM4nJRyzpHZhEdMTBODjIdcFGbPfzJXIPbavXlyzFfYDbW75Hx7fNk5wFMC/RU3PXHig=
Content-Type: application/xml
Transfer-Encoding: chunked
Date: Thu, 10 Sep 2015 15:34:51 GMT
Server: AmazonS3

comment:8 Changed on May 17, 2016 at 11:47:01 AM by e-man-calle

I also need this!

comment:9 Changed on May 18, 2016 at 3:27:27 PM by dkocher

  • Milestone changed from 5.0 to 5.1

comment:10 Changed on Jul 15, 2016 at 2:20:45 PM by dkocher

  • Summary changed from Authentication using AWS AssumeRole and GetSessionToken to Authentication using AWS AssumeRole and GetSessionToken with AWS STS

comment:11 Changed on Jul 25, 2016 at 2:33:16 PM by dkocher

If you are running Cyberduck within EC2, please refer to Connecting with temporary access credentials from EC2.

comment:12 Changed on Jul 29, 2016 at 8:02:28 AM by dkocher

Can you clarify the use case and if we should use the AWS STS API to obtain the session token from https://sts.amazonaws.com.

comment:13 Changed on Jul 29, 2016 at 8:03:23 AM by dkocher

AssumeRole

Returns a set of temporary security credentials (consisting of an access key ID, a secret access key, and a security token) that you can use to access AWS resources that you might not normally have access to. Typically, you use AssumeRole for cross-account access or federation.

comment:14 Changed on Jul 29, 2016 at 8:05:06 AM by dkocher

Do you require multi-factor authentication (MFA) information for AssumeRole?

comment:15 Changed on Aug 24, 2016 at 9:26:52 AM by dkocher

  • Milestone changed from 5.1 to 5.2

comment:16 Changed on Oct 5, 2016 at 1:39:23 PM by dkocher

  • Milestone changed from 5.2 to 5.1.3

Milestone renamed

comment:17 Changed on Oct 5, 2016 at 1:39:23 PM by dkocher

  • Milestone changed from 5.1.3 to 6.0

Ticket retargeted after milestone closed

comment:18 Changed on Oct 18, 2016 at 12:34:08 PM by dkocher

  • Milestone 6.0 deleted

comment:19 Changed on Jun 27, 2017 at 3:28:30 PM by dkocher

#9992 closed as duplicate.

comment:20 Changed on Jul 12, 2017 at 1:39:49 PM by dkocher

#10013 closed as duplicate.

comment:21 Changed on Jul 12, 2017 at 1:41:21 PM by dkocher

We possibly just need to add support to allow the input of a SessionToken in the authentication prompt to set the X-Amz-Security-Token header.

comment:22 Changed on Nov 27, 2017 at 2:22:08 PM by dkocher

  • Milestone set to 6.3.1

Related ticket #10009.

comment:23 Changed on Nov 30, 2017 at 7:21:33 PM by dkocher

  • Milestone 6.3.1 deleted

Ticket retargeted after milestone closed

comment:24 Changed on Dec 5, 2017 at 5:26:54 PM by kuhnboy

Last edited on Dec 5, 2017 at 5:27:54 PM by kuhnboy (previous) (diff)

comment:25 Changed on Dec 13, 2017 at 11:49:57 PM by mjcsb

  • Description modified (diff)
  • Type changed from enhancement to feature

I also need this.

What would be AWESOME: instead of collecting the access_key_id and secret_key, you instead would collect the $AWS_DEFAULT_PROFILE or "--profile" as used in aws s3 CLI commands, so if we have configured awscli to use roles via lines in ~/.aws/config, this would simply work without having to double-enter the data in two locations.

Happy if you provide an option to both store inside Cyberduck AND if not stored internally, attempt to lookup the profile inside ~/.aws/* too.

But, AWS best practice for the last few years has been to use role assumption in any multi-account scenario, and they've been pushing multi-account at the enterprise level also for a few years, so I think you need to prioritize this - it seems to have been a request for years now.

comment:26 Changed on Mar 26, 2018 at 4:23:49 PM by jibi-waba

What is the status of this feature request? It has been delayed and/or removed from the schedule multiple times over the past two years. As mentioned by someone else a few months ago, please make this a priority and add support for session tokens soon.

comment:28 Changed on Mar 26, 2018 at 7:23:04 PM by jibi-waba

If Cyberduck supported the use of aws_session_token from the credentials file, then this would definitely be the route to take. However, using only the aws_access_key_id and aws_secret_access_key from that file does not allow authentication to the service. It needs a combination of all three values. You may want to add support for the legacy variable name - aws_security_token - which shares the same value as aws_session_token (at least in our environment). The token information is generated via the STS service when authenticating via SAML-based identity provider (whether that is Okta or ADFS or Auth0 or other provider).

Here's a truncated profile in my credentials file:

[aws-account-name]
aws_access_key_id = ASIA...
aws_secret_access_key = ++LQV7...
aws_session_token = FQoDY...
aws_security_token = FQoDY...
last_updated = 2018-03-26T18:14:35Z

More information: https://aws.amazon.com/blogs/security/a-new-and-standardized-way-to-manage-credentials-in-the-aws-sdks/

Last edited on Mar 26, 2018 at 7:25:14 PM by jibi-waba (previous) (diff)

comment:29 Changed on Mar 26, 2018 at 7:47:24 PM by mjcsb

aws_session_token and aws_security_token are, I think, the wrong way to fix this. That's not how AWS recommends you configure cross-account roles in AWS CLI.

The original ticket description remains the correct approach, IMHO. The IAM access code should look up a profile in ~/.aws/config - NOT - specify secret/access keys explicitly. This profile may contain either the secret/access keys needed, or it may contain a role_arn combined with a reference to a source_profile. It is the combination of the source_profile to get the secret/access key, with the role_arn to assume that role in another account, which is needed to access the S3 bucket in the other account.

I'm pretty sure all the code necessary to make this work is open source and visible in the AWS CLI GitHub project, someone just needs to refactor it to work here. Not sure why this is taking so long...

comment:30 Changed on Mar 26, 2018 at 11:36:24 PM by jibi-waba

Both scenarios could/should be supported. Cyberduck should not define best practice or method. If the SDK or boto support a specific credentials configuration (or cross-account access configuration) for authentication, then clients like Cyberduck should also strive to support this authentication method(s). We have no issues with other clients, such as the AWSCLI or Terraform, supporting aws_session_token, so the expectation is that Cyberduck would also support it.

As you said, this should be a rather simple change since this is standard support within the SDK. Perhaps this needs to be split into two separate requests, but they’re closely related.

comment:31 Changed on Mar 30, 2018 at 9:57:31 PM by dkocher

  • Milestone set to 7.0

comment:32 Changed on Apr 12, 2018 at 6:51:51 PM by mcnicr

  • Keywords mfa added

I would also suggest that allowing for MFA is/should be closely tied to this feature. S3 security is at the forefront of many highlevel breaches in the news recently and permitting temporary credentials via sts:AssumeRole coupled with sts:GetSessionToken and allowing a client to use MFA significantly improves safety of data.

We have 100's of Cyberduck users who can no longer use the product due to this missing feature. I am very much looking forward to seeing this implemented so my user community can return to using CyberDuck

comment:33 Changed on May 1, 2018 at 10:01:32 AM by ekent

  • Priority changed from low to high

Are there any updates on when this will be available? I've increased the priority to high as mentioned above, hundreds of Cyberduck users are no longer able to use the product due to this missing feature. This means that potential customers will also look elsewhere. Many companies are starting to use the AssumeRole function, and so the need for this is increasing by the day. Please add the feature in soon!

My suggestion is to pull all the credentials from the .aws/credentials file, upon every connect. The contents of the file will change, and so having the ability to pull the information every time will be useful and enable users not to have to re-enter the details (for if their credentials have a timeout/expiry of 60 mins).

comment:34 Changed on May 1, 2018 at 12:11:00 PM by dkocher

Thanks everyone for the input provided!

As we are not accustomed ourselves to using session tokens, we would love to get some feedback if requirements are met when we implement this with the following constraints:

  • Read AWS credential profiles file from the default location (~/.aws/credentials). We already do this – note the AWS access key being set when you add a new bookmark and set the protocol to S3.
  • If the AWS Access Key set in the bookmark matches, read the session token.
  • We use the default profile "default" unless a custom profile name is set in the connection profile using the key Context. Refer to Profiles.
  • When Contextis set to an URL, the session token is retrieved from the EC2 instance metadata service (already supported).

comment:36 Changed on May 10, 2018 at 12:54:09 PM by jibi-waba

@dkocher, I will be more than willing to test our use case when the above constraints are accounted for. For us, the big one is the "read the session token" portion. I believe what you have stated in the above criteria will address our scenario, which is passing the session token for authentication when a named profile is referenced. Thanks for your work and research on this ticket.

comment:37 Changed on May 10, 2018 at 1:08:15 PM by mcnicr

A typical use case we have is switching roles between accounts that require MFA for the assume role to succeed. A sample of the type of config file most users are using is adding the mfa_serial to the config default profile and then referencing this in other profiles. This setup is using a single sign-on account '00000000000' for user management for passwords/access keys and MFA. Then the users will assume role into a different account to access S3.

When accessing S3 the UI should allow the user to input the MFA token to retrieve an sts:SessionToken which will carry the MFA characteristics along to be used to get sts:AssumeRole credentials.

User Credentials -> Session Credentials with MFA -> Assume Role into accounts with S3 data.

~user/.aws/config

[default]
region=us-east-1
output=json
mfa_serial=arn:aws:iam::000000000000:mfa/user@domain.com 
[profile assumerole]
role_arn=arn:aws:iam::11111111111111:role/role1account1
source_profile=default
[profile assumerole2]
role_arn=arn:aws:iam::22222222222222:role/role2account2
source_profile=default

comment:38 Changed on May 10, 2018 at 1:17:15 PM by jibi-waba

@mcnicr MFA support with session tokens might be better served as a different ticket/feature request that is dependent on this one for session token support. Just my opinion.

comment:39 Changed on May 10, 2018 at 1:28:37 PM by dkocher

  • Description modified (diff)

comment:40 follow-up: Changed on May 11, 2018 at 5:22:59 PM by dt1001

I already have a script that gets me this far in ~/.aws/credentials:

[publish_profile]
output = json
region = us-west-1
aws_access_key_id = AAAAAAAAAAAAAAAAAAAA
aws_secret_access_key = KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK
aws_session_token = SSSSSSSSSSS//////////SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS=

I want to configure Cyberduck with just profile = "publish_profile" and have it use those three values. It would also be nice to catch any expiration error so you could remind the user that their session has expired and they need to run through their external SSO tool again to refresh the aws_session_token.

comment:41 Changed on May 22, 2018 at 1:13:20 PM by dkocher

Related issue #10222 asking for generic support of MFA.

comment:42 Changed on Jul 18, 2018 at 2:00:29 PM by dkocher

Replying to tigris:

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.

AWS Vault looks like an interesting project which supports exposing credentials running a local EC2 Instance Metadata server which should work together with the profile for Connecting with temporary access credentials (Token) from EC2.

comment:43 Changed on Jul 19, 2018 at 7:37:21 PM by dkocher

  • Milestone changed from 7.0 to 6.7.0

comment:45 Changed on Jul 22, 2018 at 7:04:22 PM by dkocher

We used the following steps to test our implementation.

  1. Create an IAM user testuser
  2. Create an IAM policy userpolicy with the following policy document:
          {
            "Version": "2012­10­17",
            "Statement": [
              {
                "Effect": "Allow",
                "Action": "sts:AssumeRole",
                "Resource": "arn:aws:iam::123456789012:role/testrole",
                "Condition": {
                  "Bool": {"aws:MultiFactorAuthPresent": true}
                }
    } ]
    }
    
  3. Attach the “userpolicy” policy to the “testuser” user.
  4. Create an IAM role testrole, specifying 123456789012 as the account and electing to

require MFA.

  1. Create an IAM policy rolepolicy with the following policy document:
          {
            "Version": "2012­10­17",
            "Statement": [{
              "Effect": "Allow",
              "Action": "s3:*",
              "Resource": "*"
    }] }
    
  2. Attach the rolepolicy policy to the testrole role.
  3. Generate an access key and secret for testuser
  4. Configure an MFA device for testuser

  1. Create a file ~/.aws/credentials with the following contents (substituting where indicated):
   [testuser]
   aws_access_key_id=<access key for testuser>
   aws_secret_access_key=<secret key for testuser>
   [testrole]
   role_arn=arn:aws:iam::123456789012:role/testrole
   source_profile=testuser
   mfa_serial=arn:aws:iam::123456789012:mfa/testuser
  1. Install the S3 (Credentials from AWS Security Token Service) profile and configure a bookmark using the testrole profile by entering testrole in ‘’Profile Name’’.

comment:48 Changed on Jul 23, 2018 at 9:55:43 AM by dkocher

Skip saving temporary credentials in keychain in r44759.

comment:49 Changed on Jul 23, 2018 at 9:58:32 AM by dkocher

  • Resolution set to fixed
  • Status changed from assigned to closed

comment:50 Changed on Jul 23, 2018 at 10:53:44 AM by dkocher

Please update to the latest snapshot build available to test this integration.

comment:51 Changed on Jul 23, 2018 at 4:09:00 PM by jibi-waba

I tested this for our method of accessing AWS via a SAML provider, where the security tokens are written directly into our credentials file via a tool we use to generate those tokens via STS (post-SAML auth). I have confirmed this method is now working to access S3 buckets. Thanks again!

comment:52 follow-up: Changed on Jul 25, 2018 at 3:55:46 PM by jibi-waba

That said, it seems like the latest snapshot builds have broken our ability to use the traditional S3 profile with access/secret key auth. When prompted for secret key, clicking Login just beeps at us (multiple computers, multiple users, existing and new keys, keys work in other programs and CLIs, etc.).

comment:53 in reply to: ↑ 52 Changed on Jul 26, 2018 at 8:30:48 PM by dkocher

Replying to jibi-waba:

That said, it seems like the latest snapshot builds have broken our ability to use the traditional S3 profile with access/secret key auth. When prompted for secret key, clicking Login just beeps at us (multiple computers, multiple users, existing and new keys, keys work in other programs and CLIs, etc.).

Fix in r44807.

comment:54 in reply to: ↑ 40 Changed on Aug 3, 2018 at 5:57:16 PM by dt1001

Replying to dt1001:

I already have a script that gets me this far in ~/.aws/credentials ... I want to configure Cyberduck with just profile = "publish_profile" and have it use those three values ...

I just tested this with nightly build 28570 and it worked perfectly. Thank you so much! Really makes this enterprise friendly. Going to get my company to buy several licenses now.

comment:55 Changed on Oct 17, 2018 at 3:50:21 PM by fguerraz

Hello,

Is this supposed to work on windows? I've got the cli configured with ~/.aws/credentials and listing bucket works fine. However with the cyberduck sts profile bookmark set to the some profile, cyberduck asks for a password.

Cheers.

comment:56 follow-ups: Changed on Feb 1, 2019 at 10:14:26 AM by cduser

  • Resolution fixed deleted
  • Status changed from closed to reopened

This credentials file configuration (previously mentioned by dt001) works perfectly with commercial S3 regions (server: s3.amazonaws.com, region: us-west-1) but not with AWS GovCloud (server: s3-us-gov-west-1.amazonaws.com, region: us-gov-west-1). I'm using s3-us-gov-west-1.amazonaws.com as the "Server" and cyberduck gets into a loop where it says "Authenticating as publish_profile" followed by "Login failed". I am using version 6.9.3. Any ideas?

[publish_profile]
output = json
region = us-gov-west-1
aws_access_key_id = AAAAAAAAAAAAAAAAAAAA
aws_secret_access_key = KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK
aws_session_token = SSSSSSSSSSS//////////SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS=
Last edited on Feb 1, 2019 at 11:25:53 AM by cduser (previous) (diff)

comment:57 in reply to: ↑ 56 ; follow-up: Changed on Feb 1, 2019 at 11:21:51 AM by fguerraz

Replying to cduser:

This credentials file configuration (previously mentioned by dt001) works perfectly with commercial S3 regions (server: s3.amazonaws.com, region: us-west-1) but not with AWS GovCloud (server: s3-us-gov-west-1.amazonaws.com, region: us-gov-west-1). I'm using s3-us-gov-west-1.amazonaws.com as the "Server" and cyberduck gets into a loop where it says "Authenticating as publish_profile" followed by "Login failed". I am using version 6.9.3. Any ideas?

Did 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.

comment:58 in reply to: ↑ 57 Changed on Feb 1, 2019 at 11:25:34 AM by cduser

Replying to fguerraz:

Replying to cduser:

This credentials file configuration (previously mentioned by dt001) works perfectly with commercial S3 regions (server: s3.amazonaws.com, region: us-west-1) but not with AWS GovCloud (server: s3-us-gov-west-1.amazonaws.com, region: us-gov-west-1). I'm using s3-us-gov-west-1.amazonaws.com as the "Server" and cyberduck gets into a loop where it says "Authenticating as publish_profile" followed by "Login failed". I am using version 6.9.3. Any ideas?

Did 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.

Hi fguerraz,

Sorry. Yes I have in my credentials file us-gov-west-1 instead of us-west-1. I tried both, us-gov-west-1 fails (using the s3-us-gov-west-1.amazonaws.com server) and us-west-1 works (using the s3.amazonaws.com server). I'm going to edit my original comment to replace us-west-1 with us-gov-west-1.

Thanks!

comment:59 in reply to: ↑ 56 ; follow-up: Changed on Feb 2, 2019 at 9:19:14 PM by dkocher

Replying to cduser:

This credentials file configuration (previously mentioned by dt001) works perfectly with commercial S3 regions (server: s3.amazonaws.com, region: us-west-1) but not with AWS GovCloud (server: s3-us-gov-west-1.amazonaws.com, region: us-gov-west-1). I'm using s3-us-gov-west-1.amazonaws.com as the "Server" and cyberduck gets into a loop where it says "Authenticating as publish_profile" followed by "Login failed". I am using version 6.9.3. Any ideas?

[publish_profile]
output = json
region = us-gov-west-1
aws_access_key_id = AAAAAAAAAAAAAAAAAAAA
aws_secret_access_key = KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK
aws_session_token = SSSSSSSSSSS//////////SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS=

Can you confirm you use the AWS GovCloud connection profile from https://cyberduck.io/s3/. Please open a new ticket if the issue persists.

comment:60 Changed on Feb 2, 2019 at 9:19:22 PM by dkocher

  • Resolution set to fixed
  • Status changed from reopened to closed

comment:61 Changed on Feb 2, 2019 at 9:22:56 PM by dkocher

We fixed the connection profiles to include the region in r46225.

comment:62 in reply to: ↑ 59 Changed on Feb 2, 2019 at 9:35:13 PM by cduser

Replying to dkocher:

Replying to cduser:

This credentials file configuration (previously mentioned by dt001) works perfectly with commercial S3 regions (server: s3.amazonaws.com, region: us-west-1) but not with AWS GovCloud (server: s3-us-gov-west-1.amazonaws.com, region: us-gov-west-1). I'm using s3-us-gov-west-1.amazonaws.com as the "Server" and cyberduck gets into a loop where it says "Authenticating as publish_profile" followed by "Login failed". I am using version 6.9.3. Any ideas?

[publish_profile]
output = json
region = us-gov-west-1
aws_access_key_id = AAAAAAAAAAAAAAAAAAAA
aws_secret_access_key = KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK
aws_session_token = SSSSSSSSSSS//////////SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS=

Can you confirm you use the AWS GovCloud connection profile from https://cyberduck.io/s3/. Please open a new ticket if the issue persists.

Hi dkocher,

I tried using the AWS GovCloud connection profile (https://svn.cyberduck.io/trunk/profiles/S3%20Gov%20Cloud.cyberduckprofile). The problem is that this profile doesn't seem to have the option to use S3(Credentials from AWS Security Token Service). It seems like to use a temporary token I need to use this other profile (https://svn.cyberduck.io/trunk/profiles/S3%20(Credentials%20from%20AWS%20Security%20Token%20Service).cyberduckprofile). I tried adding the following config to the S3(Credentials from AWS Security Token Service) profile (to change the S3 URL) but didn't work (unless I'm missing something).

        <key>Default Port</key>
        <string>443</string>
        <key>Default Hostname</key>
        <string>s3-us-gov-west-1.amazonaws.com</string>

Is there a way to support both AWS GovCloud and S3 (Credentials from AWS Security Token Service).

Thanks!

Last edited on Feb 2, 2019 at 9:53:59 PM by cduser (previous) (diff)

comment:63 Changed on Feb 3, 2019 at 4:22:04 AM by cduser

Version 0, edited on Feb 3, 2019 at 4:22:04 AM by cduser (next)
Note: See TracTickets for help on using tickets.
swiss made software