@mprewitt007: This request has been added to the tracker:
Issue 1898 – Support for Amazon KMS
You can vote for it there.

So,
FileZilla and CloudBerry have inputs for S3 encryption, on this bucket, we had a specific KMS key set for the encryption. Apparently WinSCP only supports the default AWS controlled encryption, and there is no option to add the ARN for the KMS key for a per-bucket encryption key.
So this is now a feature request.
Mark

I've attached the session log.
I've used the same directory, user/key on 3 other applications and CLI and the permissions on the user are good.
Yet when I plug them into WinSCP, it throws an "access denied" error for ANY write action.

Interestingly, when I created a folder in my test folder, (/ajrdedd/ajrdedd/test) and deleted test, it deleted both test AND ajrdedd. It should have left the ajrdedd folder alone.
I tested with a file in there with the test folder and deleted it and it did not delete the parent folder, but it deleting it as the last item in the chain feels off.
It won't write, but it will delete tells me there is an issue in the syntax of this version on PutObject commands.
Mark

So I updated to 5.17 build 10640 and this oddity is back.
I use the exact same configuration on FileZilla Pro or CloudBerry and set the default folder to my test folder and I get access denied on WinSCP, but on the other tools I have no issues.
Is there a workaround for this?
As it used to work.
Mark

Thanks.
I have sent you an email with a debug version of WinSCP to the address you have used to register on this forum.
Please send me screenshots and separate trace logs from the debug version for both sessions.

So, I am looking at it, and there is >NO< difference on the hostname between the 2 accounts.
yet in the logs, one has the bucket and one does not.

If I clone the one that does not, the bucket shows up when it does DNS lookups.

I'd be happy to do a screen share to show you this, or if you give me a private location, I cant send you a screen shot of the 2 showing you that the 2 accounts are identical in the front UI, but the directories differ in that one is / and the other remote directory is <replaced>/ingest
So it appears to have something to do with the remote directory difference. / is the parent directory, /replaced/ is the sublevel and ingest is the 3rd level.

mprewitt007 wrote:

in the log where you see the hostname with the bucket is where it goes to try to access the bucket, as it adds the bucketname in front of the hostname when it tries to access it.

No. Once again, The Host name: entry in the header of the log shows exactly, what you configured on WinSCP login dialog. So if there's replaced.s3-us-gov-west-1.amazonaws.com, it's because you have configured replaced.s3-us-gov-west-1.amazonaws.com in WinSCP sessions. The replaced. part was not added by WinSCP. Can you please repeat the test?

You're talking about the hostname?
Yes, they are identical.
Both use s3-us-gov-west-1.amazonaws.com

In the log where you see the hostname with the bucket is where it goes to try to access the bucket, as it adds the bucketname in front of the hostname when it tries to access it.
I see this consistently in the logs, so I would assume this is part of how it accesses S3.
Since I haven't looked at the source code, I can't confirm this, but the behavior is consistent in any working S3 access that it hits both the hostname as entered on the main screen and bucket.hostname for bucket access.

mprewitt007 wrote:

It is consistent. We use a 'bucketname' which I don't want disclosed, so I (in both log files) replaced the bucketname with replaced.
Thus in the one log, it is doing DNS of bucketname.s3-us-gov-1.. and in the other you aren't using the bucket for some reason.

Host name: entry in the log shows exactly, what you configured in WinSCP login dialog. Please double check your settings.

It is consistent. We use a bucketname which I don't want disclosed, so I (in both log files) replaced the bucketname with replaced.
Thus in the one log, it is doing DNS of bucketname.s3-us-gov-1.. and in the other you aren't using the bucket for some reason.
They are configured the exact same as far as the WinSCP configuration, the only difference is the user/key.
This is part of why I am confused. I literally cloned the working session and only replaced it with a new access key & secret, and it broke. As I said, the other tools we use don't have an issue, but when I edited the permissions on the 'new' key, I had to grant a whole bunch of extra permissions around bucket ACL's to get it to work with winSCP.

OK, sorry. You are right. Though can you post log files again, this time with sensitive information replaced in a consistent way?

For example in winscpfailedlogin.log, there's:

While in the winscpfunctionalconnection.log, there's:

What may suggest that you have different session settings for these.

But winscpfunctionalconnection.log later shows:

With that I'm confused what was the real hostname that you have used for that session.
So can you obfuscate the changes in both logs the same way? So that I can see when the difference is real and not only due to a different obfuscation?

Yes to your question, and I thought I uploaded the log in my first post.
is there a different log I need to upload?

Do you mean that you cannot connect with WinSCP using credentials that do not have permissions to list buckets, even if you explicitly specify the bucket name in Remote directory?

Can you post a log file for that?

So, yeah, that is the host. Recall I am testing 2 access key/secret to the same bucket.
What I found through some experimentation yesterday is that WinSCP doesn't seem to be handling the bucketlist ACL's properly.
I had to grant the key I wanted to use greater ACL than is required in FileZilla or CloudBerry to be able to use the credential in WinSCP.
I had to grant it full get bucketlist for the entire masterbucket, I could not limit it to a sub-bucket, which is a requirement for our use case.
So at the moment, WinSCP is great of you are the admin of the bucket, but if I want to share a sub-folder of that bucket, it doesn't properly access the sub-buckets, it gets the access denied error because of the malformed API call its doing.
So we'll have to keep using the other tools til this is fixed, which sucks as I really prefer WinSCP.

Use s3-us-gov-west-1.amazonaws.com hostname as in the working session.

If the credentials do not have permission to list buckets, you also need to specify the bucket name directly in Remote directory as /bucket:
https://winscp.net/eng/docs/ui_login_directories

Good Day,
I downloaded the WinSCP 5.14.1 8909 build developer version in case the region detection issue in the tracker was my problem, but I don't think it is.
I have a set of S3 credentials for an S3 bucket in us-gov-west1 that I can test with FileZilla pro and CloudBerry, so I know the credentials and path are good.
In WinSCP, I get

Access Denied
Extra Details: RequestId: 5D738AFD9ADB305B, HostId: Xd4q7BJ5QoMNXEqBje7FDQU/bvHEYx21fe4TIyXXpaIBJNT1zsB3xJ28lJ5TMILmv1Wed7HylUY=
Connection failed.

With the credentials that work elsewhere. I have another credential that works in both places. These both go to the same bucket, same URL, very confused.
Any ideas?