トラブルシューティング AWS Transfer Family - AWS Transfer Family
サービス管理ユーザーのトラブルシューティングAmazon API Gateway の問題のトラブルシューティング暗号化された Amazon S3 バケットのポリシーのトラブルシューティング認証の問題のトラブルシューティングマネージド型ワークフローの問題のトラブルシューティングワークフローの復号に関する問題のトラブルシューティングAmazon EFSの問題のトラブルシューティングID プロバイダーのテストのトラブルシューティングSFTP コネクタに信頼されたホストキーを追加するトラブルシューティングファイルアップロードの問題のトラブルシューティングResourceNotFound 例外のトラブルシューティングSFTP コネクタの問題のトラブルシューティングAS2 問題のトラブルシューティング

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

トラブルシューティング AWS Transfer Family

以下の情報を使用して、 の使用時に発生する可能性のある一般的な問題を診断し、修正します AWS Transfer Family。

Transfer Family IAMの に関する問題については、「」を参照してくださいAWS Transfer Family ID とアクセスのトラブルシューティング。

サービス管理ユーザーのトラブルシューティング

このセクションでは、以下の問題に対する可能な解決策を説明します。

Amazon EFSサービスマネージドユーザーのトラブルシューティング

説明

sftp コマンドを実行した場合にプロンプトの代わりに次のメッセージが表示されることがあります。

Couldn't canonicalize: Permission denied
           Need cwd

原因

AWS Identity and Access Management （IAM) ユーザーのロールには、Amazon Elastic File System (Amazon ) にアクセスするアクセス許可がありませんEFS。

対策

ユーザーのロールについてポリシーのアクセス権限を増やします。などの AWS マネージドポリシーを追加できますAmazonElasticFileSystemClientFullAccess。

公開鍵本文が長すぎる場合のトラブルシューティング

説明

サービス管理対象ユーザーを作成しようとすると、次のエラーが表示されます。

Failed to create user (1 validation error detected:
'sshPublicKeyBody' failed to satisfy constraint: Member must have length less than or equal to 2048)

原因

パブリックPGPキー本文にキーを入力する可能性があり、 AWS Transfer Family はサービスマネージドユーザーのPGPキーをサポートしていません。

解決策

PGP キーが RSAベースの場合は、PEM形式に変換できます。例えば、Ubuntu は https://manpages.ubuntu.com/manpages/xenial/man1/openpgp2ssh.1.html という変換ツールを提供しています。

トラブルシューティングでSSHパブリックキーを追加できませんでした

説明

サービス管理ユーザーの公開鍵を追加しようとすると、次のエラーが表示されます。

Failed to add SSH public key (Unsupported or invalid SSH public key format)

原因

SSH2形式のパブリックキーをインポートしようとしている可能性があり、サービスマネージドユーザーの SSH2形式のパブリックキーをサポート AWS Transfer Family していません。

解決策

キーを OpenSSH 形式に変換する必要があります。このプロセスは、「SSH2 パブリックキーをPEM形式に変換する」で説明されています。

Amazon API Gateway の問題のトラブルシューティング

このセクションでは、以下のAPIゲートウェイの問題に対して考えられる解決策について説明します。

認証失敗の回数が多すぎる

説明

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 プロバイダをテストします。次のようなレスポンスが表示される場合、ロールARNはすべてのゼロのロール ID 値で示されるように、プレースホルダーのみです。

{
    "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. AWS CloudFormation コンソールを https://console.aws.amazon.com/cloudformation で開きます。

  2. 左のナビゲーションペインで [Stacks] (スタック) をクリックします。

  3. 「スタック」リストでスタックを選択し、「パラメータ」タブを選択します。

  4. [Update] (更新) を選択します。「スタックの更新」ページで、「現在のテンプレートを使用する」を選択し、「次へ」を選択します。

  5. を Transfer Family サーバーにアクセスするための十分なアクセス許可ARNを持つロールUserRoleArnに置き換えます。

    注記

    必要なアクセス許可を付与するには、ロールに AmazonAPIGatewayAdministrator および AmazonS3FullAccess マネージドポリシーを追加します。

  6. 「次へ」を選択し、もう一度「次へ」を選択します。レビュー時 stack 「」ページを選択し、 がIAMリソース を作成する AWS CloudFormation 可能性があることを確認してから、スタック の更新「」を選択します。

接続が終了する

説明

Secure Shell (SSH) File Transfer Protocol () を使用してサーバーに接続しようとするSFTPと、次のエラーが発生します。

Connection closed

原因

この問題の考えられる原因の 1 つは、Amazon CloudWatch ログ記録ロールが Transfer Family と信頼関係がないことです。

解決策

サーバのロギングロールが Transfer Family と信頼関係にあることを確認します。詳細については、「信頼関係を確立するには」を参照してください。

暗号化された Amazon S3 バケットのポリシーのトラブルシューティング

説明

暗号化された Amazon S3 バケットがTransfer Family サーバーのストレージとして使用されています。サーバーにファイルをアップロードしようとすると、「Couldn't close file: Permission denied」エラーが表示されます。

そしてサーバーログを表示すると、次のエラーが表示されます。

ERROR Message="Access denied" Operation=CLOSE Path=/bucket/user/test.txt BytesIn=13
ERROR Message="Access denied"

原因

IAM ユーザーのポリシーには、暗号化されたバケットにアクセスするアクセス許可がありません。

解決策

必要な AWS Key Management Service (AWS KMS) アクセス権限を付与するには、ポリシーに追加のアクセス権限を指定する必要があります。詳細については、「Amazon S3 でのデータ暗号化」を参照してください。

認証の問題のトラブルシューティング

このセクションでは、以下の認証の問題に対して考えられる解決策について説明します。

認証の失敗 —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.
注記

Gateway を使用していて、このエラーが表示された場合は、API「」を参照してください認証失敗の回数が多すぎる。

原因

ユーザーのRSAキーペアを追加していないため、代わりにパスワードを使用して認証する必要があります。

解決策

sftp コマンドを実行する際、-o PubkeyAuthentication=no オプションを指定します。このオプションは、システムにパスワードを要求させます。例:

sftp -o PubkeyAuthentication=no sftp-user@server-id.server.transfer.region-id.amazonaws.com

マネージド AD のレルム不一致問題

説明

ユーザーのレルムとグループのレルムを一致する必要があります。両方ともデフォルトレルム内にあるか、または両方とも信頼されるレルムに属している必要があります。

原因

ユーザーとそのグループが一致しない場合、そのユーザーはTTransfer Family ilyによって認証されません。ユーザーの ID プロバイダーをテストすると、「ユーザーのグループに関連するアクセスが見つかりません」というエラーが表示されます。

解決策

グループレルム (デフォルトまたは信頼できる) と一致するユーザーのレルム内のグループを参照します。

その他の認証に関する問題

説明

認証エラーが発生し、他のトラブルシューティングは実行されません。

原因

先頭または末尾にスラッシュ (/) を含む論理ディレクトリのターゲットを指定した可能性があります。

解決策

論理ディレクトリのターゲットを更新して、先頭がスラッシュで、末尾にスラッシュが含まれていないことを確認してください。例えば、 /DOC-EXAMPLE-BUCKET/imagesは許容されますが、 DOC-EXAMPLE-BUCKET/images と /DOC-EXAMPLE-BUCKET/images/は許容されません。

マネージド型ワークフローの問題のトラブルシューティング

このセクションでは、以下のワークフローの問題に対して考えられる解決策について説明します。

Amazon を使用したワークフロー関連のエラーのトラブルシューティング CloudWatch

説明

ワークフローに問題がある場合は、Amazon CloudWatch を使用して原因を調査できます。

原因

いくつかの原因が考えられるので、Amazon CloudWatch Logs を使用して調査します。

解決策

Transfer Family は、ワークフロー実行ステータスを CloudWatch Logs に出力します。 CloudWatch ログには、次のタイプのワークフローエラーが表示されることがあります。

  • "type": "StepErrored"

  • "type": "ExecutionErrored"

  • "type": "ExecutionThrottled"

  • "Service failure on starting workflow"

ワークフローの実行ログは、異なるフィルターやパターン構文を使ってフィルターすることができます。例えば、 CloudWatch ログにログフィルターを作成して、ExecutionErroredメッセージを含むワークフロー実行ログをキャプチャできます。詳細については、「Amazon Logs ユーザーガイド」の「サブスクリプションを使用したログデータのリアルタイム処理」および「フィルターとパターン構文」を参照してください。 CloudWatch

StepErrored

2021-10-29T12:57:26.272-05:00
            {"type":"StepErrored","details":{"errorType":"BAD_REQUEST","errorMessage":"Cannot
            tag Efs file","stepType":"TAG","stepName":"successful_tag_step"},
            "workflowId":"w-abcdef01234567890","executionId":"1234abcd-56ef-78gh-90ij-1234klmno567",
            "transferDetails":{"serverId":"s-1234567890abcdef0","username":"lhr","sessionId":"1234567890abcdef0"}

ここで、StepErrored はワークフロー内のステップでエラーを生成したことを示します。1 つのワークフローには複数のステップを設定できます。このエラーでは、どのステップでエラーが発生したかがエラーメッセージに表示されます。この特定の例では、ステップはファイルにタグ付けするように設定されていますが、Amazon EFS ファイルシステム内のファイルのタグ付けはサポートされていないため、ステップはエラーを生成しました。

ExecutionErrored

2021-10-29T12:57:26.618-05:00
            {"type":"ExecutionErrored","details":{},"workflowId":"w-w-abcdef01234567890",
            "executionId":"1234abcd-56ef-78gh-90ij-1234klmno567","transferDetails":{"serverId":"s-1234567890abcdef0",
            "username":"lhr","sessionId":"1234567890abcdef0"}}

ワークフローで実行できないステップがあると、「ExecutionErrored」というメッセージが表示されます｡ たとえば、特定のワークフローに設定したステップのうち 1 つのステップを実行できないと、ワークフロー全体が失敗します。

Executionthrottled

ワークフローが、システムがサポートできる速度よりも速い速度でトリガーされる場合、実行はスロットルされます。このログメッセージは、ワークフローの実行速度を落とす必要があることを示しています。ワークフロー実行率をスケールダウンできない場合は、 連絡先 AWS AWS Support にお問い合わせください。

ワークフロー開始時に発生したサービス障害

サーバーからワークフローを削除し、新しいワークフローに置き換える場合、またはサーバー構成を更新する場合（ワークフローの実行ロールに影響する）、新しいワークフローを実行する前に約 10 分間待機する必要があります。Transfer Family サーバーはワークフローの詳細をキャッシュし、サーバーがキャッシュを更新するのに10分かかります。

さらに、アクティブなSFTPセッションからログアウトし、10 分間の待機期間後に再度ログインして変更を確認する必要があります。

ワークフローコピーエラーのトラブルシューティング

説明

アップロードされたファイルをコピーするステップを含むワークフローを実行している場合、以下のエラーが発生する可能性がある：

{
  "type": "StepErrored", "details": {
    "errorType": "BAD_REQUEST", "errorMessage": "Bad Request (Service: Amazon S3; Status Code: 400; Error Code: 400 Bad Request;
    Request ID: request-ID; S3 Extended Request ID: request-ID Proxy: null)", "stepType": "COPY", "stepName": "copy-step-name" },
  "workflowId": "workflow-ID",
  "executionId": "execution-ID",
  "transferDetails": {
     "serverId": "server-ID",
     "username": "user-name",
     "sessionId": "session-ID"
  }
}

原因

ソースファイルは、送信先バケット AWS リージョン とは異なる Amazon S3 バケットにあります。

解決策

コピーステップを含むワークフローを実行する場合、コピー元とコピー先のバケットが同じ AWS リージョンにあることを確認します。

ワークフローの復号に関する問題のトラブルシューティング

説明

復号ワークフローが失敗し、ログメッセージが次のように表示されます。

{
   "type": "StepErrored",
   "details": {
      "errorType": "BAD_REQUEST",
      "errorMessage": "File encryption algorithm not supported with FIPS mode enabled.",
      "stepType": "DECRYPT",
      "stepName": "step-name"
   },
   "workflowId": "workflow-ID",
   "executionId": "execution-ID",
   "transferDetails": {
      "serverId": "server-ID",
      "username": "user-name",
      "sessionId": "session-ID"
   }
}

原因

Transfer Family サーバーではFIPS、モードが有効になっており、関連する復号ワークフローステップがあります。Transfer Family サーバーにアップロードする前にファイルを暗号化する場合、暗号化クライアントは、FIPS承認されていない対称暗号化アルゴリズムを使用する暗号化ファイルを生成することがあります。このようなシナリオでは、ワークフローはファイルを復号化できません。次の例では、GnuPG バージョン 2.4.0 は OCB (ブロックFIPS以外の暗号モード) を使用してファイルを暗号化しています。これにより、ワークフローが失敗します。

解決策

ファイルの暗号化に使用したGPGキーを編集してから、再暗号化する必要があります。次の手順では、実行する必要のある手順について説明します。

PGP キーを編集するには

  1. 次のコマンドを実行して、編集する必要のあるキーを特定します。gpg ‐‐list-keys

    これにより、キーのリストが返されます。各キーには次のような詳細が含まれます。

    pub   ed25519 2022-07-07 [SC]
      wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
uid           [ultimate] Mary Major <marymajor@example.com>
sub   cv25519 2022-07-07 [E]

  2. 編集するキーを特定します。前の手順で示した例では、ID はwJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEYです。

  3. gpg ‐‐edit-key wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY を実行します。

    システムから GnuPG プログラムと指定されたキーに関する詳細を応答します。

  4. gpg>プロンプトで、showprefを入力します。以下の詳細情報が返されます。

    [ultimate] (1). Mary Major <marymajor@example.com>
   Cipher: AES256, AES192, AES, 3DES
   AEAD: OCB
   Digest: SHA512, SHA384, SHA256, SHA224, SHA1
   Compression: ZLIB, BZIP2, ZIP, Uncompressed
   Features: MDC, AEAD, Keyserver no-modify

    キーに保存されている推薦アルゴリズムが一覧表示されていることに注意してください。

  5. キーを編集して、 を除くすべてのアルゴリズムを保持しますOCB。setpref保持するすべてのアルゴリズムを指定してコマンドを実行します。

    gpg> setpref AES256, AES192,AES,3DES,SHA512, SHA384, SHA256, SHA224, SHA1,ZLIB, BZIP2, ZIP, Uncompressed

    これは以下の詳細を返す：

    Set preference list to:
     Cipher: AES256, AES192, AES, 3DES
     AEAD: 
     Digest: SHA512, SHA384, SHA256, SHA224, SHA1
     Compression: ZLIB, BZIP2, ZIP, Uncompressed
     Features: MDC, Keyserver no-modify
Really update the preferences? (y/N)

  6. 「yupdate」と入力して更新し、変更を確認するプロンプトが表示されたらパスワードを入力します。

  7. 変更を保存します。

    gpg> save

復号化ワークフローを再実行する前に、編集したキーを使用してファイルを再暗号化する必要があります。

Amazon EFSの問題のトラブルシューティング

このセクションでは、以下の Amazon EFSの問題に対して考えられる解決策について説明します。

欠落しているPOSIXプロファイルのトラブルシューティング

説明

サーバーに Amazon EFSストレージを使用していて、カスタム ID プロバイダーを使用している場合は、 POSIX プロファイルを AWS Lambda 関数に提供する必要があります。

原因

考えられる原因の 1 つは、 AWS Lambdaでバックアップされた Amazon API Gateway メソッドを作成するために指定したテンプレートに現在POSIX情報が含まれていないことです。

POSIX 情報を提供した場合、POSIX情報提供に使用した形式が Transfer Family によって正しく解析されない可能性があります。

解決策

PosixProfile パラメータの Transfer Family に JSON要素を指定していることを確認します。

例えば、Python を使用している場合、PosixProfile パラメータをパースする箇所に以下の行を追加することができる：

if PosixProfile: 
        response_data["PosixProfile"] = json.loads(PosixProfile)

または、 で次の行 JavaScriptを追加できます。 uid-valueおよび gid-valueは、それぞれユーザー ID (UID) とグループ ID (GID) を表す整数 0 以上です。

PosixProfile: {"Uid": uid-value, "Gid": gid-value},

これらのコード例は、文字列としてではなくJSONオブジェクトとして Transfer Family に PosixProfileパラメータを送信します。

また、 内には AWS Secrets Manager、次のように PosixProfileパラメータを保存する必要があります。your-uid と をyour-gid、 GIDと の実際の値に置き換えますUID。

{"Uid": your-uid, "Gid": your-gid, "SecondaryGids": []}

Amazon で論理ディレクトリをトラブルシューティングする EFS

説明

ユーザーのホームディレクトリが存在せず、ユーザーが ls コマンドを実行すると、システムは次のように応答します。

sftp> ls
remote readdir ("/"): No such file or directory

原因

Transfer Family サーバーが Amazon を使用している場合EFS、ユーザーが論理ホームディレクトリで作業する前に、ユーザーのホームディレクトリを読み取りおよび書き込みアクセスで作成する必要があります。ユーザーは自分の論理ホームディレクトリに対する mkdir の権限がないため、このディレクトリを自分で作成することはできません。

解決策

親ディレクトリへの管理アクセス権を持つユーザーは、ユーザーの論理ホームディレクトリを作成する必要があります。

ID プロバイダーのテストのトラブルシューティング

説明

コンソールまたはTestIdentityProviderAPI呼び出しを使用して ID プロバイダーをテストする場合、 Responseフィールドは空です。例:

{
    "Response": "{}",
    "StatusCode": 200,
    "Message": ""
}

原因

最も考えられる原因は、ユーザー名やパスワードが間違っているために認証が失敗したことです。

解決策

ユーザーの認証情報が正しいことを確認し、必要に応じてユーザー名またはパスワードを更新してください。

SFTP コネクタに信頼されたホストキーを追加するトラブルシューティング

説明

SFTP コネクタを作成または編集していて、信頼できるホストキーを追加すると、次のエラーが表示されます。 Failed to edit connector details (Invalid host key format.)

原因

正しいパブリックキーに貼り付けた場合、問題は comment key. AWS Transfer Family does currently accept the comment portion of the key.

解決策

キーのコメント部分をテキストフィールドに貼り付けると、そのキーのコメント部分が削除されます。例えば、あなたのキーが以下のようなものだとする：

ssh-rsa AAAA...== marymajor@dev-dsk-marymajor-1d-c1234567.us-east-1.amazon.com

==文字の後に続くテキストを削除し、キーの最初の部分と==を含む部分だけを貼り付けます。

ssh-rsa AAAA...==

ファイルアップロードの問題のトラブルシューティング

このセクションでは、以下のファイルアップロードの問題に対して考えられる解決策について説明します。

Amazon S3 ファイルアップロードエラーのトラブルシューティング

説明

Transfer Family を使用して Amazon S3 ストレージにファイルをアップロードしようとすると、次のエラーメッセージが表示されます。AWS Transfer は S3 オブジェクトへのランダムアクセス書き込みをサポートしていません。

原因

サーバーのストレージに Amazon S3 を使用している場合、Transfer Family は 1 回の転送で複数の接続をサポートしていません。

解決策

Transfer Family サーバーのストレージに Amazon S3 を使用している場合は、1 回の転送に複数の接続を使用することを記載しているクライアントソフトウェアのオプションをすべて無効にします。

読み取り不可能なファイル名のトラブルシューティング

説明

アップロードしたファイルの一部に壊れたファイル名が表示される。ユーザー名、アクセント付き文字、中国語FTPやアラビア語などの特定のスクリプトなど、ファイル名に特定の文字を書き込む問題やSFTP転送が発生することがあります。

原因

FTP および SFTPプロトコルでは、クライアントがファイル名の文字エンコードをネゴシエートできますが、Amazon S3 と Amazon EFSはネゴシエートできません。代わりに、UTF-8 文字のエンコードが必要です。その結果、特定の文字が正しく表示されません。

解決策

この問題を解決するには、クライアントアプリケーションでファイル名文字エンコーディングを確認し、それが UTF-8 に設定されていることを確認します。

ResourceNotFound 例外のトラブルシューティング

説明

リソースが見つからないというエラーが表示されます。例えば、UpdateServerを実行すると、エラーが返されます。

An error occurred (ResourceNotFoundException) when calling the UpdateServer operation: Unknown server

原因

ResourceNotFoundException メッセージを受信する理由はいくつかあります。ほとんどの場合、APIコマンドで指定したリソースは存在しません。既存のリソースを指定した場合、最も可能性の高い原因は、デフォルトリージョンがリソースのリージョンと異なることです。例えば、デフォルトのリージョンが us-east-1 で、Transfer Family サーバーが us-east-2 にある場合、「未知リソース」例外が発生します。

デフォルトリージョンの設定について詳しくは、「によるクイック設定」を参照してください。aws configure

解決策

API コマンドにリージョンパラメータを追加して、特定のリソースの場所を明示的に指定します。

aws transfer -describe-server --server-id server-id --region us-east-2

SFTP コネクタの問題のトラブルシューティング

このセクションでは、以下のSFTPコネクタの問題に対して考えられる解決策について説明します。

キーネゴシエーションが失敗する

説明

キー交換ネゴシエーションが失敗するエラーが表示されます。例:

Key exchange negotiation failed due to incompatible host key algorithms. 
Client offered: [ecdsa-sha2-nistp256, ecdsa-sha2-nistp384,
ecdsa-sha2-nistp521, rsa-sha2-512, rsa-sha2-256] Server offered: [ssh-rsa]

原因

このエラーは、サーバーがサポートするホストキーアルゴリズムとコネクタがサポートするホストキーアルゴリズムが重複していないためです。

解決策

リモートサーバーが、エラーメッセージに記載されているクライアントホストキーアルゴリズムの少なくとも 1 つをサポートしていることを確認してください。サポートされているアルゴリズムのリストについては、「SFTP コネクタアルゴリズム」を参照してください。

その他のSFTPコネクタの問題

説明

の実行後にエラーが発生しますがStartFileTransfer、問題の原因は不明であり、API呼び出し後にコネクタ ID のみが返されます。

原因

このエラーにはいくつかの原因が考えられます。トラブルシューティングを行うには、コネクタをテストし、 CloudWatch ログを検索することをお勧めします。

解決策

  • コネクタをテストする: を参照してくださいSFTP コネクタをテストする。テストに失敗した場合、システムは失敗の理由に基づいたエラーメッセージを提供します。このセクションでは、 コンソールまたは を使用してコネクタをテストする方法について説明します。 TestConnection API コマンド。

  • コネクタの CloudWatch ログを表示する: を参照してくださいSFTP コネクタのログエントリの例。このトピックでは、SFTPコネクタログエントリの例と、適切なログを見つけるのに役立つ命名規則について説明します。

AS2 問題のトラブルシューティング

Applicability Statement 2 (AS2) 対応サーバーのエラーメッセージとトラブルシューティングのヒントについては、「」を参照してくださいAS2 エラーコード。