AWS Transfer Family（SFTP）のエラーを検証してみた
はじめに
アノテーション クラウド運用チームの森です。
今回は、AWS Transfer Family（SFTP）で発生する可能性がある様々なエラーケースを検証し、エラーメッセージの違いから問題を特定する方法をまとめました。
各エラーが発生する状況を事前に理解することで、実際にエラーが発生した際に原因特定がしやすくなります。
背景
AWS Transfer Family の公式ドキュメント でログ出力について説明はされていますが、どのような状況でどのログが記録されるのかを明確にイメージできませんでした。
以下記事でもトラブルシューティングについてまとまっていましたが、ログ出力が現在の内容と異なったため自分で検証することにしました。
前提条件
- AWS Transfer Family で SFTP サーバーを作成している
- セキュリティグループで SSH 接続を許可している
- ドメインとして S3 を指定している
- 適切な IAM ロールをアタッチしたユーザーを作成している
やってみた
今回検証したユースケースは以下のとおりです。
- 正常なアクセス
- 認証エラー
- ケース 1: 存在しないユーザーでのアクセス
- ケース 2: 鍵不一致
- セキュリティグループ拒否
- IAM ロールの権限不足
- ケース 1: ポリシーの不足
- ケース 2: 信頼関係の不足
- S3 バケット不在
1. 正常なアクセス
まずは、正常なアクセスをした際に、どのようにログが記録されるかを確認します。
sftp -i ~/.ssh/test-key.pem test-user@s-xxx.server.transfer.ap-northeast-1.amazonaws.com
ターミナル出力:
Connected to s-xxx.server.transfer.ap-northeast-1.amazonaws.com.
CloudWatch Logs:
{
"role": "arn:aws:iam::123456789012:role/mori-test-transfer-role",
"activity-type": "CONNECTED",
"ssh-public-key-fingerprint": "SHA256:IczaCbl50Uq6ROaYd4CMvo725gWLrhUG9Ap7DC/lWdg",
"home-dir": "/mori-test-bucket-123456789012/test-user",
"ssh-public-key": "AAAAB3NzaC1yc2EAAAADAQABAAABAQDfia…",
"ssh-public-key-type": "ssh-rsa",
"macs": "hmac-sha2-256-etm@openssh.com,hmac-sha2-256-etm@openssh.com",
"ciphers": "aes128-ctr,aes128-ctr",
"client": "SSH-2.0-OpenSSH_9.9",
"source-ip": "192.0.2.1",
"resource-arn": "arn:aws:transfer:ap-northeast-1:123456789012:server/s-xxx",
"user": "test-user",
"kex": "curve25519-sha256",
"session-id": "02153e506ea92347a687"
}
ログストリーム: s-xxx/test-user
2. 認証エラー（AUTH_FAILURE）
ケース 1: 存在しないユーザー
存在しないユーザー（nonexistent-user）で接続してみます。
sftp -i ~/.ssh/test-key.pem nonexistent-user@s-xxx.server.transfer.ap-northeast-1.amazonaws.com
ターミナル出力:
Permission denied (publickey).
Connection closed
CloudWatch Logs:
{
"method": "publickey",
"activity-type": "AUTH_FAILURE",
"source-ip": "192.0.2.1",
"resource-arn": "arn:aws:transfer:ap-northeast-1:123456789012:server/s-xxx",
"message": "Authentication failure",
"user": "nonexistent-user"
}
ログストリーム: ERRORS
このログが確認できた場合は、サーバー詳細のユーザーに接続ユーザーが存在するかを確認しましょう。
ケース 2: 鍵不一致
新しく作成したキーを利用して接続してみます。
sftp -i ~/.ssh/wrong-key.pem test-user@s-xxx.server.transfer.ap-northeast-1.amazonaws.com
ターミナル出力:
Permission denied (publickey).
Connection closed
CloudWatch Logs:
{
"method": "publickey",
"activity-type": "AUTH_FAILURE",
"source-ip": "192.0.2.1",
"resource-arn": "arn:aws:transfer:ap-northeast-1:123456789012:server/s-xxx",
"message": "RSA SHA256:AMwZVhXWegE9iHlL5+7T4E+4ndQ2cI6cnhev1OXM4pU",
"user": "test-user"
}
ログストリーム: ERRORS
鍵が不一致の場合、ログのメッセージに公開鍵のフィンガープリントが表示されます。
このログが確認できた場合は、ユーザー詳細のフィンガープリントが、メッセージに出力されたものと一致するかを確認しましょう。
ケース 1 と 2 のどちらでも AUTH_FAILURE が記録されますが、メッセージ内容が異なることがわかります。
3. ネットワークエラー
セキュリティグループで接続元 IP を拒否
セキュリティグループからインバウンドルールを削除し、接続してみます。
ターミナル出力:
ssh: connect to host s-xxx.server.transfer.ap-northeast-1.amazonaws.com port 22: Connection timed out
最初は何も出力されませんが、しばらく放置しているとタイムアウトします。
CloudWatch Logs: 出力なし
TCP レベルで接続が確立しないため、Transfer Family にはリクエストが到達しません。
4. IAM ロールの権限不足
ケース 1: ポリシーの不足
IAM ロールから S3 関連の許可ポリシーをすべて削除し接続してみます。
sftp -i ~/.ssh/test-key.pem test-user@s-xxx.server.transfer.ap-northeast-1.amazonaws.com
# 接続成功
sftp> ls
ターミナル出力:
Couldn't read directory: Permission denied
CloudWatch Logs:
{
"activity-type": "ERROR",
"resource-arn": "arn:aws:transfer:ap-northeast-1:123456789012:server/s-xxx",
"message": "Access denied",
"session-id": "0181c5cb55ae2432e158"
}
また、mkdir コマンドや、存在しないディレクトリで ls コマンドを実行すると以下ログも出力されました。
{
"s3extended-request-id": "Dly0L3GqttAMw14GGrO8Ra/27XTS3QF7eT7mr96uqvXvskwB2gnGz7zlFCO+8b66/9hRV4atJUY=",
"path": "/mori-test-bucket-123456789012/test-user",
"activity-type": "ERROR",
"resource-arn": "arn:aws:transfer:ap-northeast-1:123456789012:server/s-xxx",
"message": "Access denied",
"request-id": "6CC6DWGV1B2ZAPXP",
"operation": "MKDIR",
"session-id": "0181c5cb55ae2432e158"
}
ケース 2: 信頼関係の不足
IAM ロールの信頼関係を削除してから接続してみます。
sftp -i ~/.ssh/test-key.pem test-user@s-xxx.server.transfer.ap-northeast-1.amazonaws.com
# 接続成功
sftp> ls
ターミナル出力:
Couldn't read directory: Permission denied
CloudWatch Logs: 出力なし
ただし、mkdir コマンドや、存在しないディレクトリで ls コマンドを実行すると以下ログが出力されました。
{
"path": "/mori-test-bucket-123456789012/test",
"activity-type": "ERROR",
"resource-arn": "arn:aws:transfer:ap-northeast-1:123456789012:server/s-xxx",
"message": "Unable to AssumeRole for user",
"operation": "MKDIR",
"session-id": "0298e24edf1871918caf"
}
ケース 1 と 2 では、ターミナル上のエラー表示は共通していますが、CloudWatch Logs を確認することで原因の特定ができることがわかりました。
また、IAM ロール自体を削除した状態で接続した場合もケース 2 と同じ結果になりました。
5. S3 バケット不在
IAM ロールの権限等はもとに戻した状態で、存在しない S3 バケットへアクセスを試してみます。
# ルートディレクトリで実行
sftp> ls test123
ターミナル出力:
Couldn't read directory: Failure
CloudWatch Logs:
{
"activity-type": "ERROR",
"resource-arn": "arn:aws:transfer:ap-northeast-1:123456789012:server/s-xxx",
"message": "Error performing readdir",
"session-id": "007176aa84676b8f04c1"
}
なお、存在しないディレクトリへの ls はターミナル上ではエラーになるものの、ログに記録されません。
まとめ
| ユースケース | 接続 | ログストリーム | ログ種別 | メッセージ | 原因 |
|---|---|---|---|---|---|
| 存在しないユーザーでのアクセス | ☓ | ERRORS | AUTH_FAILURE | "Authentication failure" | 認証 |
| 鍵不一致 | ☓ | ERRORS | AUTH_FAILURE | 鍵フィンガープリント | 認証 |
| SG 拒否 | ☓ | - | - | - | ネットワーク |
| S3 権限不足 | ○ | s-xxx/test-user | ERROR | "Access denied" | IAM（ポリシー） |
| 信頼関係の不足 | ○ | s-xxx/test-user | ERROR | "Unable to AssumeRole for user" | IAM（信頼関係） |
| S3 バケット不在 | ○ | s-xxx/test-user | ERROR | "Error performing readdir" | S3 |
ログの記録場所
- 認証エラー（AUTH_FAILURE）:
ERRORSログストリームに記録 - 操作エラー（ERROR）: ユーザーごとのログストリーム（
s-xxx/test-user）に記録 - ネットワークレベルのエラー: ログに記録されない
ポイント
- IAM ロール/S3 権限に問題があっても接続は成功する
- ターミナル上のエラー出力だけでは原因の特定はできない
- CloudWatch Logs を確認することで原因を判別できる
参考
AWS 運用代行・サーバー監視のご案内
クラスメソッド マネージドサービス は、AWS 国内支援実績 No.1 のクラスメソッドが提供する、クラウド特有の対応やクラウド技術者の不足に課題をお持ちのお客様向けの AWS 運用トータル支援サービスです。
監視や運用支援にとどまらず、お客様のクラウド利用を最適化し日々の負担を最小化することで、お客様のビジネス効果の最大化を支援します。
アノテーション株式会社について
アノテーション株式会社はクラスメソッドグループのオペレーション専門特化企業です。サポート・運用・開発保守・情シス・バックオフィスの専門チームが、最新 IT テクノロジー、高い技術力、蓄積されたノウハウをフル活用し、お客様の課題解決を行っています。当社は様々な職種でメンバーを募集しています。「オペレーション・エクセレンス」と「らしく働く、らしく生きる」を共に実現するカルチャー・しくみ・働き方にご興味がある方は、アノテーション株式会社 採用サイト をぜひご覧ください。
