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という秘密鍵、ユーザは存在しない想定とします。

![スライド1.PNG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2523652/c853c3e5-ef19-0183-44a9-2921c7eae31b.png)

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

# 正常接続時

```shell
sftp -i ~/.ssh/user0001 user0001@vpce-xxx.vpce-svc-xxx.ap-northeast-1.vpce.amazonaws.com
```

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

```shell
{
    "role": "arn:aws:iam::xxx:role/xxx",
    "activity-type": "CONNECTED",
    "macs": "<implicit>,<implicit>",
    "ciphers": "aes256-gcm@openssh.com,aes256-gcm@openssh.com",
    "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"
}
```

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


```shell
sftp -i ~/.ssh/user0002 user0001@vpce-xxx.vpce-svc-xxx.ap-northeast-1.vpce.amazonaws.com
```

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

```shell
{
    "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"
}
```


# パターン②(利用するユーザが存在しない)
```shell
sftp -i ~/.ssh/user0002 user9999@vpce-xxx.vpce-svc-xxx.ap-northeast-1.vpce.amazonaws.com
```

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

```shell
{
    "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"
}
```

# パターン③(利用する秘密鍵が存在しない)
```shell
sftp -i ~/.ssh/user9999 user0001@vpce-xxx.vpce-svc-xxx.ap-northeast-1.vpce.amazonaws.com
```

`ユーザ：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.
```

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

```shell
cp user0002 id_ed25519
sftp -i ~/.ssh/user9999 user0001@vpce-xxx.vpce-svc-xxx.ap-northeast-1.vpce.amazonaws.com
```

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

```shell
{
    "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の記事

https://qiita.com/infra365/items/666676d861db733fa73d

https://qiita.com/infra365/items/bf2918625d6d3c8038bf