连接到AWS Transfer for SFTP

Question

我无法连接到AWS Transfer for SFTP.我成功设置了服务器并尝试使用WinSCP进行连接.

我设置了一个具有信任关系的IAM角色,如下所示:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "transfer.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

我使用主目录和主目录将文档中描述的范围向下策略与此配对homebuckethomedir

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "ListHomeDir",
            "Effect": "Allow",
            "Action": [
                "s3:ListBucket",
                "s3:GetBucketAcl"
            ],
            "Resource": "arn:aws:s3:::${transfer:HomeBucket}"
        },
        {
            "Sid": "AWSTransferRequirements",
            "Effect": "Allow",
            "Action": [
                "s3:ListAllMyBuckets",
                "s3:GetBucketLocation"
            ],
            "Resource": "*"
        },
        {
            "Sid": "HomeDirObjectAccess",
            "Effect": "Allow",
            "Action": [
                "s3:DeleteObjectVersion",
                "s3:DeleteObject",
                "s3:PutObject",
                "s3:GetObjectAcl",
                "s3:GetObject",
                "s3:GetObjectVersionAcl",
                "s3:GetObjectTagging",
                "s3:PutObjectTagging",
                "s3:PutObjectAcl",
                "s3:GetObjectVersion"
            ],
            "Resource": "arn:aws:s3:::${transfer:HomeDirectory}*"
        }
    ]
}

}

我能够使用ssh密钥进行身份验证,但是当实际读取/写入文件时,我只是不断出现"错误查找homedir"和"readdir"失败等不透明错误.这一切都与我的IAM政策问题非常相似,但我无法弄明白.

Answer 1

我们在将范围缩小策略与AWS Transfer上的用户一起使用时遇到了类似的问题。对我们有用的解决方案是创建两种不同的策略。

• 赋予在整个存储桶中具有一般权限的角色的策略。
• 范围缩小策略适用于使用诸如的传输服务变量的用户{transfer:UserName}。

我们得出的结论是，也许只有附加的附加策略才能解决传输服务变量。我们不确定这是否正确以及这是否是最佳解决方案，因为这在允许附加范围缩小策略以创建一种“管理员”用户时会带来潜在的风险。因此，我很高兴能得到进一步的锁定。

查看转移用户详细信息时，它在控制台中的外观如下：

这是我们使用的两个策略：
附加到IAM角色的常规策略

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowListingOfUserFolder",
            "Action": [
                "s3:ListBucket",
                "s3:GetBucketLocation"
            ],
            "Effect": "Allow",
            "Resource": [
                "arn:aws:s3:::my-s3-bucket"
            ]
        },
        {
            "Sid": "HomeDirObjectAccess",
            "Effect": "Allow",
            "Action": [
                "s3:PutObject",
                "s3:GetObject",
                "s3:DeleteObjectVersion",
                "s3:DeleteObject",
                "s3:GetObjectVersion"
            ],
            "Resource": "arn:aws:s3::: my-s3-bucket/*"
        }
    ]
}

范围缩小政策适用于转移用户

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowListingOfUserFolder",
            "Action": [
                "s3:ListBucket"
            ],
            "Effect": "Allow",
            "Resource": [
                "arn:aws:s3:::${transfer:HomeBucket}"
            ],
            "Condition": {
                "StringLike": {
                    "s3:prefix": [
                        "${transfer:UserName}/*",
                        "${transfer:UserName}"
                    ]
                }
            }
        },
        {
            "Sid": "AWSTransferRequirements",
            "Effect": "Allow",
            "Action": [
                "s3:ListAllMyBuckets",
                "s3:GetBucketLocation"
            ],
            "Resource": "*"
        },
        {
            "Sid": "HomeDirObjectAccess",
            "Effect": "Allow",
            "Action": [
                "s3:PutObject",
                "s3:GetObject",
                "s3:DeleteObjectVersion",
                "s3:DeleteObject",
                "s3:GetObjectVersion"
            ],
            "Resource": "arn:aws:s3:::${transfer:HomeDirectory}*"
        }
    ]
}

Answer 2

I had a similar problem but with a different error behavior. I managed to log in successfully, but then the connection was almost immediately closed. I did the following things:

• Make sure that the IAM role that allows bucket access also contains KMS access if your bucket is encrypted.
• Make sure that the trust relationship is also part of that role.
• Make sure that the server itself has a Cloudwatch role also with a trust relationship to transfer.amazonaws.com! This was the solution for me. I don't get why this is needed but without the trust relationship in the Cloudwatch role, my connection get's closed.

I hope that helps. Edit: Added a picture for the settings of the CloudWatch role:

The bucket policy for the IAM user role can look like this:

{
"Version": "2012-10-17",
"Statement": [
    {
        "Effect": "Allow",
        "Action": [
            "s3:ListBucket"
        ],
        "Resource": [
            "arn:aws:s3:::<your bucket>"
        ]
    },
    {
        "Effect": "Allow",
        "Action": [
            "s3:PutObject",
            "s3:GetObject",
            "s3:DeleteObject"
        ],
        "Resource": [
            "arn:aws:s3:::<your bucket>/*"
        ]
    }
]

}

Finally, also add a Trust Relationship as shown above for the user IAM role.

If you can connect to your sftp but then get a readdir error when trying to list contents, e.g. with the command "ls", then that's a sign that you have no bucket permission. If your connection get's closed right away it seems to be a Trust Relationship issue or a KMS issue.