Hi. I've been trying to replace SSH with SSM start-session in our environment because I want the additional logging and detection/response benefits. However, for our production systems, we currently require a Yubikey 2FA authorization on every SSH login. I cannot find an equivalent way to accomplish this security control via SSM start-session. We have tried adding a linux login script to enforce it, but the session can still be started if that script fails. Is there any way to accomplish this? If there is not an existing method that I missing, would you be open to a pull request to add this capability to the agent if we developed it? Sorry for the "issue", but I wanted to make sure you were open to the idea before I invested resources in it.
Please note: requiring 2FA in the IAM policy is not a sufficient replacement for our purposes. The security control needs to be an explicit 2FA authorization upon every SSM amazon-ssm-agent to the instance/container. The attack vector being guarded against is an assume client endpoint compromise, so the AWS tokens are assumed stolen off the client endpoint from ~/.aws/credentials or similar .
Hi. I've been trying to replace SSH with SSM start-session in our environment because I want the additional logging and detection/response benefits. However, for our production systems, we currently require a Yubikey 2FA authorization on every SSH login. I cannot find an equivalent way to accomplish this security control via SSM start-session. We have tried adding a linux login script to enforce it, but the session can still be started if that script fails. Is there any way to accomplish this? If there is not an existing method that I missing, would you be open to a pull request to add this capability to the agent if we developed it? Sorry for the "issue", but I wanted to make sure you were open to the idea before I invested resources in it.
Please note: requiring 2FA in the IAM policy is not a sufficient replacement for our purposes. The security control needs to be an explicit 2FA authorization upon every SSM amazon-ssm-agent to the instance/container. The attack vector being guarded against is an assume client endpoint compromise, so the AWS tokens are assumed stolen off the client endpoint from ~/.aws/credentials or similar .