AWS Transfer Family（SFTP）認証失敗時ログが記録されないパターン

内容

AWS Transfer Familyというより、SFTP(SSH)の動作になりますが、下記Transfer Familiyを使用したSFTP環境で認証時ログ記録の仕様を試しました。

検証用環境

VPC内のEC2サーバからTransfer Family経由でS3に接続する構成となります。秘密鍵・公開鍵を用いたユーザ認証を行い、認証時のログはCloudWatch Logsに記録される構成とします。Transfer Familyにユーザ：user0001とキーペア：user0001を作成。公開鍵をTransfer Familyサーバ側、秘密鍵を接続元のEC2サーバに保存します。検証パターンは①～③とします。なおuser0002という秘密鍵、ユーザは存在し、user9999という秘密鍵、ユーザは存在しない想定とします。

結論

パターン①②はCloudWatch Logsに記録される。
パターン③はCloudWatch Logsに記録されない。
※ただし③でもデフォルトの認証キーが存在する場合は記録される。（後述）

正常接続時

sftp -i ~/.ssh/user0001 [e-mail]

ユーザ：user0001、秘密鍵：user0001を使用した正常に接続可能なパターンです。CloudWatch Logsに"activity-type": "CONNECTED"、また接続に使用した暗号化アルゴリズムなどが記録されます。

{
    "role": "arn:aws:iam::xxx:role/xxx",
    "activity-type": "CONNECTED",
    "macs": "<implicit>,<implicit>",
    "ciphers": "[e-mail],[e-mail]",
    "client": "SSH-2.0-OpenSSH_8.7",
    "source-ip": "xxx",
    "resource-arn": "arn:aws:transfer:ap-northeast-1:xxx:server/xxx",
    "home-dir": "LOGICAL",
    "user": "user0001",
    "kex": "curve25519-sha256",
    "session-id": "xxx"
}

パターン①(利用する秘密鍵が間違っている)

sftp -i ~/.ssh/user0002 [e-mail]

ユーザ：user0001、秘密鍵：user0002を使用したパターンです。user0002という秘密鍵はEC2上に存在しますが、user0001用の秘密鍵ではないため、認証に失敗します。下記の様な内容がCloudWatch Logsに保存されます。

{
    "method": "publickey",
    "activity-type": "AUTH_FAILURE",
    "source-ip": "xxx",
    "resource-arn": "arn:aws:transfer:ap-northeast-1:xxx:server/xxx",
    "message": "ED25519 SHA256:xxx",
    "user": "user0001"
}

パターン②(利用するユーザが存在しない)

sftp -i ~/.ssh/user0002 [e-mail]

ユーザ：user9999、秘密鍵：user0002を使用したパターンです。user9999というユーザは存在しないため、認証に失敗します。下記の様な内容がCloudWatch Logsに保存されます。

{
    "method": "publickey",
    "activity-type": "AUTH_FAILURE",
    "source-ip": "xxx",
    "resource-arn": "arn:aws:transfer:ap-northeast-1:xxx:server/xxx",
    "message": "Authentication failure",
    "user": "user9999"
}

パターン③(利用する秘密鍵が存在しない)

sftp -i ~/.ssh/user9999 [e-mail]

ユーザ：user0001、秘密鍵：user9999を使用したパターンです。user0001というユーザは存在しますが、user9999という秘密鍵は存在しないため、認証に失敗します。CloudWatch Logsを確認しましたが、認証ログは記録されていませんでした。下記接続元（EC2サーバ側）のデバックログ（一部抜粋）を確認すると、鍵認証は行われていますが、秘密鍵が存在しないため、その後id_ed25519などのデフォルトの鍵で認証を試行します。しかし、デフォルトの鍵も存在しないため、通信を行っていないといったログを確認することが出来ます。

debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /root/.ssh/id_rsa
debug1: Trying private key: /root/.ssh/id_ed25519
debug3: no such identity: /root/.ssh/id_ed25519: No such file or directory
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.

パターン③(利用する秘密鍵が存在しない)　⇒　デフォルトの鍵を作成する。

cp user0002 id_ed25519
sftp -i ~/.ssh/user9999 [e-mail]

上記デフォルトの秘密鍵を作成後、パターン③を試すと、秘密鍵は存在しない⇒その後、デフォルトの秘密鍵を使用して認証失敗。このパターンだと下記の様な内容がCloudWatch Logsに保存されます。

{
    "method": "publickey",
    "activity-type": "AUTH_FAILURE",
    "source-ip": "xxx",
    "resource-arn": "arn:aws:transfer:ap-northeast-1:xxx:server/xxx",
    "message": "ED25519 SHA256:xxxxx",
    "user": "user0001"
}

その他Transfer Familyの記事