翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# 認証の問題のトラブルシューティング
このセクションでは、以下の認証の問題に対して考えられる解決策について説明します。
**Topics**
+ [認証エラー-SSH/SFTP](#publickey-auth)
+ [マネージド AD のレルム不一致問題](#managed-ad-realms-mismatched)
+ [Active Directory グループの制限を超えました](#managed-ad-group-limits)
+ [その他の認証に関する問題](#misc-auth-issues)
+ [Amazon API Gateway の問題をトラブルシューティングする](#transfer-apigateway)
+ [ID プロバイダーのテストのトラブルシューティング](#blank-test-identity-provider)
+ [ウェブアプリで Amazon S3 バケットを複製する](#webapp-duplicate-buckets)
## 認証エラー-SSH/SFTP
**説明**
Secure Shell (SSH) File Transfer Protocol (SFTP) を使用してサーバーに接続しようとすると、次のようなメッセージが表示されす。
```
Received disconnect from 3.130.115.105 port 22:2: Too many authentication failures
Authentication failed.
```
**注記**
API Gateway を使用していて、このエラーが表示される場合は、[認証失敗の回数が多すぎる](#auth-failures-sftp)を参照してください。
**原因**
ユーザーの RSA キーペアを追加していないので、代わりにパスワードを使って認証する必要があります。
**解決策**
`sftp` コマンドを実行する際、`-o PubkeyAuthentication=no` オプションを指定します。このオプションは、システムにパスワードを要求させます。例えば、次のようになります。
```
sftp -o PubkeyAuthentication=no sftp-user@server-id.server.transfer.region-id.amazonaws.com
```
## マネージド AD のレルム不一致問題
**説明**
ユーザーのレルムとグループのレルムを一致する必要があります。両方ともデフォルトレルム内にあるか、または両方とも信頼されるレルムに属している必要があります。
**原因**
ユーザーとそのグループが一致しない場合、そのユーザーはTTransfer Family ilyによって認証されません。ユーザーの ID プロバイダーをテストすると、「ユーザーのグループに関連するアクセスが見つかりません」というエラーが表示されます。
**解決策**
グループレルム (デフォルトまたは信頼できる) と一致するユーザーのレルム内のグループを参照します。
## Active Directory グループの制限を超えました
**説明**
AWS Transfer Family サーバーに Active Directory グループを追加しようとすると、許可されるグループの最大数に達したことを示すエラーが表示されます。
**原因**
AWS Transfer Family のデフォルトの制限は、サーバーあたり 100 Active Directory グループです。
**解決策**
考えられる解決策は 2 つあります。
+ Active Directory グループを統合して、必要な合計数を減らします。
+ ユースケースで 100 を超えるグループが必要な場合は、「カスタム ID プロバイダー[による Active Directory 認証の簡素化」の説明に従って、カスタム ID プロバイダーソリューションの使用を検討してください AWS Transfer Family](https://aws.amazon.com/blogs/storage/simplify-active-directory-authentication-with-a-custom-identity-provider-for-aws-transfer-family/)。
## その他の認証に関する問題
**説明**
認証エラーが発生し、他のトラブルシューティングは実行されません。
**原因**
先頭または末尾にスラッシュ (/) を含む論理ディレクトリのターゲットを指定した可能性があります。
**解決策**
論理ディレクトリのターゲットを更新して、先頭がスラッシュで、末尾にスラッシュが含まれていないことを確認してください。たとえば、 `/amzn-s3-demo-bucket/images`は許容されますが、 `amzn-s3-demo-bucket/images`と `/amzn-s3-demo-bucket/images/`は許容されません。
## Amazon API Gateway の問題をトラブルシューティングする
このセクションでは、以下の API Gateway の問題に対して考えられる解決策について説明します。
**Topics**
+ [認証失敗の回数が多すぎる](#auth-failures-sftp)
+ [接続が終了する](#connection-closed)
### 認証失敗の回数が多すぎる
**説明**
Secure Shell (SSH) File Transfer Protocol (SFTP) を使用してサーバーに接続しようとすると、次のエラーが発生します。
```
Received disconnect from 3.15.127.197 port 22:2: Too many authentication failures
Authentication failed.
Couldn't read packet: Connection reset by peer
```
**原因**
入力したユーザーパスワードが正しない可能性があります。もう一度、正しいパスワードを入力してみてください。
パスワードが正しい場合、この問題はロールの Amazon リソースネーム（ARN）が有効でないことが原因かもしれません。それが原因であることを確認するには、サーバーの ID プロバイダをテストします。次のようなレスポンスが表示される場合、すべてがゼロのロール ID 値は、ロール ARN がプレースホルダーのみであることを示します。
```
{
"Response": "{\"Role\": \"arn:aws:iam::000000000000:role/MyUserS3AccessRole\",\"HomeDirectory\": \"/\"}",
"StatusCode": 200,
"Message": "",
"Url": "https://api-gateway-ID.execute-api.us-east-1.amazonaws.com/prod/servers/transfer-server-ID/users/myuser/config"
}
```
**解決策**
プレースホルダーロール ARN をサーバーへのアクセス権限がある実際のロールに置き換えます。
**ロールを更新するには**
1.
[https://console.aws.amazon.com/cloudformation](https://console.aws.amazon.com/cloudformation/) で CloudFormation コンソールを開きます。
1. 左のナビゲーションペインで **[Stacks]** (スタック) をクリックします。
1. 「**スタック**」リストでスタックを選択し、「**パラメータ**」タブを選択します。
1. **[更新]** を選択します。「**スタックの更新**」ページで、「**現在のテンプレートを使用する**」を選択し、「**次へ**」を選択します。
1. 「**UserRoleArn**」を、Transfer Family サーバーへのアクセスに十分な権限を持つロール ARN に置き換えます。
**注記**
必要なアクセス許可を付与するには、ロールに `AmazonAPIGatewayAdministrator` および `AmazonS3FullAccess` マネージドポリシーを追加します。
1. 「**次へ**」を選択し、もう一度「**次へ**」を選択します。***スタック*の確認**ページで、 **が IAM リソースを作成する AWS CloudFormation 可能性があることを確認**してから、**スタックの更新**を選択します。
### 接続が終了する
**説明**
Secure Shell (SSH) File Transfer Protocol (SFTP) を使用してサーバーに接続しようとすると、次のエラーが発生します。
```
Connection closed
```
**原因**
この問題の原因として考えられるのは、Amazon CloudWatch のロギングロールが Transfer Family と信頼関係を持っていないことです。
**解決策**
サーバのロギングロールが Transfer Family と信頼関係にあることを確認します。詳細については、「[信頼関係を確立するには](requirements-roles.md#establish-trust-transfer)」を参照してください。
## ID プロバイダーのテストのトラブルシューティング
**説明**
コンソールまたは `TestIdentityProvider` API オペレーションを使用して ID プロバイダーをテストする場合、 `Response`フィールドは空です。例えば、次のようになります。
```
{
"Response": "{}",
"StatusCode": 200,
"Message": ""
}
```
**原因**
最も考えられる原因は、ユーザー名やパスワードが間違っているために認証が失敗したことです。
**解決策**
ユーザーの認証情報が正しいことを確認し、必要に応じてユーザー名またはパスワードを更新してください。
## ウェブアプリで Amazon S3 バケットを複製する
**説明**
同じ Amazon S3 バケットが Transfer Family ウェブアプリケーションインターフェイスに複数回表示されます。
**原因**
これは、ユーザーが同じ Amazon S3 バケットへの許可を持つ複数の Active Directory グループに属している場合に発生します。ウェブアプリケーションは、同じバケットロケーションへの重複許可を含め、ユーザーの UID または GID に関連付けられたすべての最上位許可を一覧表示します。
**解決策**
重複した出品を防ぐには、各ユーザーに Amazon S3 の場所ごとに 1 つの権限のみを持たせるように権限を統合します。Amazon S3 Access Grants の設定を確認し、異なる Active Directory グループ間で同じバケットの冗長な許可を削除します。