How to Log and Control SSH Key Authentication in AWS Transfer Family with Custom Identity Provider?

When using AWS Transfer Family with a custom identity provider, there are some differences in how password-based and SSH key-based authentication are handled. Unfortunately, there isn't a direct way to intercept or validate SSH key authentication within your custom identity provider Lambda function in the same way you can with password-based authentication.

For SSH key-based authentication, the process works as follows:

1. The Transfer Family server triggers your Lambda function.
2. Your Lambda function returns the client's public SSH key.
3. Transfer Family internally handles the authentication by verifying the provided private key against the public key.

This means that you don't have direct control over the validation step for SSH key authentication, and you can't directly track whether the SSH authentication was successful or not from within your Lambda function.

However, there are some approaches you can consider for more consistent logging and tracking across both authentication methods:

1. Use CloudWatch Logs: While not ideal for centralized tracking, CloudWatch logs generated by the Transfer Family server do provide information about successful and failed login attempts for both password and SSH key authentication. You could set up log parsing and analysis to extract this information.

2. Implement custom logging: In your Lambda function, you can log when it's called for SSH key authentication. While this won't capture the final authentication result, it will at least record the attempt.

3. Use CloudWatch Events: You can set up CloudWatch Events to trigger on successful logins to your Transfer Family server. This could then invoke another Lambda function to log the successful authentication, regardless of the method used.

4. Leverage AWS CloudTrail: CloudTrail can capture API calls made to Transfer Family, which could include successful authentication events.

5. Consider using the AWS Transfer Family custom identity provider toolkit: This solution provides a flexible foundation for implementing custom identity providers with granular per-user session configuration. It includes features for detailed logging and supports both password and public key authentication flows.

While these approaches don't provide the same level of control as password-based authentication within your Lambda function, they can help you achieve more consistent logging across both authentication methods. The best approach may depend on your specific requirements and the level of detail you need in your logs.

Remember, when using multiple authentication methods (like both password and SSH key), Transfer Family treats these as separate requests to your custom identity provider, but their effect is combined. Both requests must return successfully for the authentication to complete.
Sources
Using multiple authentication methods - AWS Transfer Family
Custom identity provider solution - AWS Transfer Family
IdentityProviderDetails - AWS Transfer Family

Hi,

Not sure how your lambda function code looks like, ideally if you use Custom IDP in this case, the Lambda function. Transfer Family server sends authentication and autherization requests to Lambda function. Lambda function should take care of both.

Have you looked at the custom-IDP toolkit that we have in the Github repo? This is the most flexible way of custom IDP implimentation. https://github.com/aws-samples/toolkit-for-aws-transfer-family/tree/main/solutions/custom-idp

If you explore this repo, it has the ready lambda function codes that you can reference.

Adding more clarity here for SSH key validation. I was checking it with internal team and its confirmed that AWS Transfer Family service will always takes care of SSH key validation which is by design.

"The validation process is integral to the SSH protocol's security design. Unfortunately, it's not feasible to externalize this validation while maintaining the protocol's integrity. SSH involves a series of sensitive cryptographic operations that require a multi-step process. These steps are carefully designed to keep private data secure within the SSH protocol handler. While we understand the desire for flexibility, altering this core aspect of SSH could potentially compromise its security features."

Hope that provides more clarity to your question.