[Cyberduck-trac] [Cyberduck] #10432: The AWS Access Key Id you provided does not exist in our records error when using S3 STS Profile

Cyberduck trac at cyberduck.io
Fri Aug 17 08:10:06 UTC 2018


#10432: The AWS Access Key Id you provided does not exist in our records error when
using S3 STS Profile
-------------------------+------------------------
 Reporter:  ekent        |         Owner:  dkocher
     Type:  defect       |        Status:  new
 Priority:  normal       |     Milestone:
Component:  s3           |       Version:  6.7.0
 Severity:  normal       |    Resolution:
 Keywords:               |  Architecture:
 Platform:  macOS 10.12  |
-------------------------+------------------------
Description changed by dkocher:

Old description:

> Since 6.7.0 there has been a functionality to use temporary credentials
> (session keys) for accessing S3.
> I've downloaded the correct STS S3 profile and filled out the bookmark
> correctly.
> I use a in house saml script to authenticate me and then create me an
> access key, secret key and session key, which are automatically put in
> the .aws/credentials file.
> If I use these credentials with the aws cli (for example `aws --profile
> test s3 ls`) it works without any issues.
> If I try to use Cyberduck however (specifying the same profile name) I
> get the following message:
> Cannot read bucket versioning status
>
> {{{
> The AWS Access Key Id you provided does not exist in our records. Please
> contact your web hosting service provider for assistance.
>
> }}}
>
> The profile in question has full S3 access, and so the message of cannot
> read bucket versioning status is wrong.
>
> The one thing I am questioning is - we use a AWS account to authenticate
> and then we assume cross account roles to access the other
> accounts/services. The profile (which is a role on a child account) works
> fine using the CLI. Is it possible that Cyberduck is ignoring the role
> and just trying to login to the authentication AWS account?
>
> Credentials file looks like the following:
>
> {{{
> [default]
> aws_access_key_id = keyidhere
> aws_secret_access_key = keyhere
> aws_session_token = sessiontokenhere
>
> [profile testrole]
> role_arn = arn:aws:iam::account:role/testrole
> source_profile = default
> }}}
>
> Log Drawer:
> {{{
> GET /?versioning HTTP/1.1
> Date: Tue, 14 Aug 2018 10:16:56 GMT
> x-amz-request-payer: requester
> x-amz-content-sha256:
> e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
> Host: redacted.s3.amazonaws.com
> x-amz-date: 20180814T101656Z
> Authorization: ********
> Connection: Keep-Alive
> User-Agent: Cyberduck/6.7.0.28613 (Mac OS X/10.12.6) (x86_64)
> HTTP/1.1 403 Forbidden
> x-amz-request-id: 416DA0A1C78F8DED
> x-amz-id-2:
> WqSZzm4AZAmxLTim+sXL4AcaoI07aQZFrwoJwDecMbTO6DVYUQhF/qOWn2TKT2PFaZ0ynuikQeM=
> Content-Type: application/xml
> Transfer-Encoding: chunked
> Date: Tue, 14 Aug 2018 10:16:46 GMT
> Server: AmazonS3
> }}}
>
> This is currently stopping our ability to use the product for its
> intended purpose.
> Any ideas?

New description:

 Since 6.7.0 there has been a functionality to use temporary credentials
 (session keys) for accessing S3.
 I've downloaded the correct STS S3 profile and filled out the bookmark
 correctly.
 I use a in house saml script to authenticate me and then create me an
 access key, secret key and session key, which are automatically put in the
 `.aws/credentials` file.
 If I use these credentials with the aws cli (for example `aws --profile
 test s3 ls`) it works without any issues.
 If I try to use Cyberduck however (specifying the same profile name) I get
 the following message:
 Cannot read bucket versioning status

 {{{
 The AWS Access Key Id you provided does not exist in our records. Please
 contact your web hosting service provider for assistance.

 }}}

 The profile in question has full S3 access, and so the message of cannot
 read bucket versioning status is wrong.

 The one thing I am questioning is - we use a AWS account to authenticate
 and then we assume cross account roles to access the other
 accounts/services. The profile (which is a role on a child account) works
 fine using the CLI. Is it possible that Cyberduck is ignoring the role and
 just trying to login to the authentication AWS account?

 Credentials file looks like the following:

 {{{
 [default]
 aws_access_key_id = keyidhere
 aws_secret_access_key = keyhere
 aws_session_token = sessiontokenhere

 [profile testrole]
 role_arn = arn:aws:iam::account:role/testrole
 source_profile = default
 }}}

 Log Drawer:
 {{{
 GET /?versioning HTTP/1.1
 Date: Tue, 14 Aug 2018 10:16:56 GMT
 x-amz-request-payer: requester
 x-amz-content-sha256:
 e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
 Host: redacted.s3.amazonaws.com
 x-amz-date: 20180814T101656Z
 Authorization: ********
 Connection: Keep-Alive
 User-Agent: Cyberduck/6.7.0.28613 (Mac OS X/10.12.6) (x86_64)
 HTTP/1.1 403 Forbidden
 x-amz-request-id: 416DA0A1C78F8DED
 x-amz-id-2:
 WqSZzm4AZAmxLTim+sXL4AcaoI07aQZFrwoJwDecMbTO6DVYUQhF/qOWn2TKT2PFaZ0ynuikQeM=
 Content-Type: application/xml
 Transfer-Encoding: chunked
 Date: Tue, 14 Aug 2018 10:16:46 GMT
 Server: AmazonS3
 }}}

 This is currently stopping our ability to use the product for its intended
 purpose.
 Any ideas?

--

--
Ticket URL: <https://trac.cyberduck.io/ticket/10432#comment:7>
Cyberduck <https://cyberduck.io>
Libre FTP, SFTP, WebDAV, S3 & OpenStack Swift browser for Mac and Windows


More information about the Cyberduck-trac mailing list