AWS transfer documentation change
Summary
Updated host key selection logic explanation and added security note about client behavior when multiple key types exist
Security assessment
The changes add a security note explaining potential client-side security warnings when adding new key types (ECDSA/ED25519) alongside existing RSA keys. While this addresses security awareness, there's no evidence of patching a specific vulnerability - rather it's documenting expected client behavior.
Diff
diff --git a/transfer/latest/userguide/server-host-key-add.md b/transfer/latest/userguide/server-host-key-add.md index 62ee5c756..d407ce3f9 100644 --- a/transfer/latest/userguide/server-host-key-add.md +++ b/transfer/latest/userguide/server-host-key-add.md @@ -11 +11,9 @@ On the AWS Transfer Family console, you can add additional server host keys. Add -The SFTP client connects using the first public key it has that can match one of the active server keys. +The SFTP client will connect using the oldest key in the configuration that matches the key's algorithm. The oldest key for each key type (RSA, ECDSA, or ED25519) is the active key for the server for that type. + +###### Security note when a Transfer Family server has multiple types of host keys + +If a server has multiple types of host keys, the SFTP client can assign a preference by type. So, when there exist RSA, ECDSA, and ED25519 host keys for the server, the choice is driven by the preference by type. + +Modern SFTP clients prefer ECDSA and ED25519 host keys when they exist. This becomes important if you want to add an ECDSA or ED25519 key when the server previously only had RSA keys. The addition of the new ECDSA or ED25519 key would potentially manifest as a security warning for a client. + +To the client, the key will appear as having changed, when in fact it was not changed: the new key was added in addition to the existing RSA key. Keep this in mind if you decide to add new types of server host keys.