[Bug] S3 authentication regression in Cyberduck 9.3.1 (44136)SummaryCyberduck 9.3.1 (44136) fails to list or access S3 buckets using valid AWS Access Key / Secret Key credentials. Downgrading to 9.2.4 resolves the issue immediately without any configuration changes, confirming a version-specific regression. Environment
Steps to reproduce
Expected: Buckets list normally and are accessible. Actual: Connection fails — buckets are not listed and cannot be accessed. VerificationThe same credentials work correctly in all of the following:
Screenshots
First screenshot: initial login attempt. Second screenshot: error shown when retrying the connection without re-entering credentials.Notes
|
Answered by
dkocher
Jul 1, 2026
Replies: 18 comments 1 reply
|
Please include the transcript from the log ouput. |
0 replies
Cyberduck S3 Connection Issue InvestigationLog FilesNo relevant output was written to According to the documentation:
However, in this case nothing was written there during the failing attempts. Transcript CaptureInstead, I captured the HTTP transcript using: This successfully logged the request/response flow. I am attaching:
Observed Difference Between Versions9.3.1 (Failing)Initial request: GET / HTTP/1.1
Host: s3.amazonaws.comResponse: HTTP/1.1 307 Temporary Redirect
Location: https://aws.amazon.com/s3/Cyberduck then follows the redirect and performs: GET /s3/ HTTP/1.1
Host: aws.amazon.comResponse: HTTP/1.1 200 OK
Content-Type: text/htmlThis results in an HTML response from the AWS website instead of an XML response from Amazon S3. 9.2.4 (Working)Initial request: GET / HTTP/1.1
Host: s3.amazonaws.com Response: HTTP/1.1 200 OK
Content-Type: application/xml
Server: AmazonS3The expected XML response is returned and buckets are listed correctly. ObservationThe only change between tests:
9.2.4 receives a proper XML response from Amazon S3. This may indicate a change in how redirects or S3 endpoint resolution are handled in 9.3.x. I am not certain whether this is related to recent internal changes, but the behavior difference is reproducible and version-specific. |
0 replies
|
Can you enable the Debug option for the log output in Preferences → Connection and provide |
0 replies
|
The |
0 replies
|
I see the same issue in mountainduck 5.2.1 in OSX. I can provide logs if that would help. |
0 replies
Please attach the logs or send to support. |
0 replies
|
Please also reproduce in the current snapshot build. |
0 replies
|
I have this issue with 9.5.0 and any prior versions I happened to test (not sure which), I have had to remain at 9.2.4 since December 2025 as well. I finally got a chance to do some debugging. To be absolutely clear: the credentials in my .aws credentials file were absolutely valid during this time and worked with 9.2.4. Using those exact same credentials in 9.5.0, it fails. However, interesting, I was able to work around this. In the attached logs, the first attempt fails consistent with the bug. But the second attempt worked by performing the following steps: (1) Edit the bookmark, click in the "profile name" field. Add a space; delete that space, and then hit connect. (Or you can delete a character and add it back). Modifying that field and clicking connect from within the bookmark works. But you have to modify the field. Double clicking the list of bookmarks or clicking connect without modifying the field, yields the same error. This is infinitely reproducible. And the credentials work for future actions for that connection until you quit. Logs attached. The UNsuccessful connection was in the first few seconds of the logs and the bookmark "fake edit" and valid connection starts about 5 seconds later. All of this is captured in about 10 seconds of logs. I will also note that the "blocked by service control policy" is expected. That is present for years. Cloudfront is not permitted in our organization but that does not impact S3. That service control policy block has been in place for years (and was in place when I could connect to S3 in 9.2.4 but maybe that needs to be trapped for as well). [ |
0 replies
|
I suspect this to be a duplicate for #18230 for which a fix is available in the current snapshot build. |
0 replies
|
Unfortunately, snapshot build 9.5.2 did not fix this problem for me. Not
only did it not fix the problem, but the oddly unique workaround that I
stumbled across no longer works in 9.5.2.
The logs I submitted were tight to show whittle down to the http calls.
To recap, the exact same bookmark, long-ago created yields the following:
9.2.4: no issues
9.5.0: fails with screen shot below, and is consistent with descriptions in
17874 but has a bizarre, repeatable, UI/UX workaround.
9.5.2 (snapshot build): fails with same screenshot below and the workaround
from 9.5.0 is now gone.
The security token is most assuredly valid.
In case it matters, here's a sample of what my redcated .aws credentials
file looks like. I put profile information into the credentials which is
allowed.
<details>
```
[profile 1]
aws_access_key_id = ASIA****REDACTED
aws_secret_access_key = g0ca+NS****REDACTED
aws_session_token = FZXIvYXasdzENX//////////wEaDPalMwJNU9Rs5****REDACTED
expiration = 2026-06-17T23:33:16
region = us-east-1
cli_pager =
cli_timestamp_format = iso8601
output = table
[profile 2]
aws_access_key_id = ASIA****REDACTED
aws_secret_access_key = HgGez7N****REDACTED
aws_session_token = FwXIvf3YXdzEOf//////////wEaaDOIVKGzjmtF5****REDACTED
expiration = 2026-06-29T09:04:59
region = us-east-1
cli_pager =
cli_timestamp_format = iso8601
output = table
[profile 3]
aws_access_key_id = ASIA****REDACTED
aws_secret_access_key = IP/r7+M****REDACTED
aws_session_token = FwoGZXIXdsdzEOf//////////wEaDeEi8kfVGrOs****REDACTED
expiration = 2026-06-29T09:04:59
region = us-east-1
cli_pager =
cli_timestamp_format = iso8601
output = json
[profile 4]
aws_access_key_id = ASIA****REDACTED
aws_secret_access_key = qt0eMT1****REDACTED
aws_session_token = FwoGZvf3YXdzEOf//////////wEaDGepWbGe****REDACTED
expiration = 2026-06-29T09:04:59
region = us-east-1
cli_pager =
cli_timestamp_format = iso8601
output = yaml
[dozens and dozens more lines]
```
</details>
|
0 replies
|
@connerat I suspect the issue you are having is different from the problem described by the author @jcitalan of this bug report. The problem with your static configuration from AWS CLI is most probably that we do not read the You may want to use a role based configuration that allows us to assume the role from static credentials. See the section Connecting Using AssumeRole from AWS Security Token Service. |
0 replies
|
Hi @dkocher : Thank you. However, I switched to the STS menu option and started with a fresh .aws credentials file with exactly one profile and including only the three required elements for that profile (aws_access_key_id, aws_secret_access_key, aws_session_token). Using only that profile and the exact same Cyberduck bookmark, connections fail in 9.5.2, but still works in 9.2.4. I did a side-by-side of the logs for you with 9.2.4 on the left and 9.5.2 on the right. In [Thread-96] which is 9.2.4, log row 1874 is present and the assertion is on row 1894. In [Thread-98] which is 9.5.2, I would expect to see ch.cyberduck.core.s3.S3Session around row 4896. It's missing. And a few rows leter, the x-amz-security-token does not appear at all in 9.5.2. The 9.2.4 and 9.5.2 are sharing the exact same library, config, preferences. I simply launch 9.2.4, double click the bookmark, and it works. I launch 9.5.2, double click the bookmark, and it fails. The side-by-side logs seem to support this. The image is wide, but it has the logs lined up perfectly for a diff. I hope this gets you what you need. -John 
|
0 replies
|
@connerat Still trying to trace down your case. Can you confirm you have set the AWS CLI profile name in the bookmark configuration, logged as |
0 replies
|
Hi @dkocher Thanks for trying to get to root cause. Yes, the profile cyberduck-bug-testing is identical in both attempts, is visible in the UI/UX (panel has changed between versions but to the human, the value in the field appears the same, and in the right place). I grepped on the AWS CLI profile name in the logs and the working version is at the top and the non-working version is at the bottom. Pasted below and attached. These are the same logs as the screen shot above from the same dead-simple comparision test. Let me know if you think I should purge all preferences, profiles, history, application support, etc. That seems dramatic, but maybe I've got some sort of malformed cruft in my prior bookmarks or connection strings? Thanks! -John Redacted Logs for cyberduck-bug-testing.txt Raw logs pasted below matching the attached.
Details
Details |
0 replies
|
Using the same redacted logs shared above, I broke down and ask ChatGPT for some help. While this is consistent with everything we've seen, it may frame this issue in a useful way. For sure, this recap of the logs matches the behavior I am seeing and how I interpret the Amazon API calls (and assertions) as well. For what it's worth. Everything below is AI-generated: Details
|
0 replies
|
Still not able to reproduce with a AWS CLI profile that includes @connerat Can you share the full log file from the failed connect attempt with the 9.5.2 snapshot build or share it with mailto:support@cyberduck.io. |
0 replies
|
Logs sent via private email. -John
…On Tue, Jun 30, 2026 at 6:30 AM David Kocher ***@***.***> wrote:
*dkocher* left a comment (iterate-ch/cyberduck#17874)
<#17874 (comment)>
Still not able to reproduce with a AWS CLI profile that includes
aws_session_token which is included in the STS GetCallerIdentity request
as expected in the X-Amz-Security-Token header and AWS4 signature.
@connerat <https://github.com/connerat> Can you share the full log file
from the failed connect attempt with the 9.5.2 snapshot build or share it
with ***@***.*** ***@***.***>.
—
Reply to this email directly, view it on GitHub
<#17874?email_source=notifications&email_token=APUXEL5XKZTDY4CDXC5T55D5COJCRA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOBUGIZTSNJYGA22M4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-4842395805>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/APUXEL5LZA45ZHZZN7XJ22D5COJCRAVCNFSNUABEKJSXA33TNF2G64TZHM3TSNJWGQ4TCMJ3JFZXG5LFHMZTSMZUGI3DQOBVGCQXMAQ>
.
Triage notifications, keep track of coding agent tasks and review pull
requests on the go with GitHub Mobile for iOS
<https://github.com/notifications/mobile/ios/APUXEL5KIEP7PLZ4EIV2OET5COJCRA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOBUGIZTSNJYGA22M4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJKTGN5XXIZLSL5UW64Y>
and Android
<https://github.com/notifications/mobile/android/APUXEL44XF3TJJG6IKYSJTT5COJCRA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOBUGIZTSNJYGA22M4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLTGN5XXIZLSL5QW4ZDSN5UWI>.
Download it today!
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
0 replies
|
Make sure to open Preferences > Profiles to update the S3 (Credentials from AWS Command Line Interface) connection profile with the change 1 that ensures reading access keys from the AWS CLI configuration. |
1 reply
|
Opened #18254 as already installed connection profiles are apparently not updated. |
Answer selected by
dkocher
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Make sure to open Preferences > Profiles to update the S3 (Credentials from AWS Command Line Interface) connection profile with the change 1 that ensures reading access keys from the AWS CLI configuration.