amazon-ssm-agent: Configurable timeout for Session Manager sessions on the CLI
Apologies if this is not the right place to request this.
I was wanting to request the ability to configure the Session Manager session timeout when connecting via CLI.
When performing long-running jobs such as database imports - and therefore not actively interacting with the terminal - I’m occasionally seeing this:
SessionId: tim.malone-097bc8bd07a0dee95 : Your session timed out due to inactivity and has been terminated.
before the job has been completed.
Would it be possible to configure (or even remove) this timeout?
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Reactions: 42
- Comments: 30 (1 by maintainers)
+1. ec2 timeout defaults are annoying; what were you thinking when you were developing such a customer focussed tool?
We really should be able to use this as a complete terminal replacement, at the moment you can’t run long-running task in this terminal without turning it into a service or some such. Timeout really needs to be configurable we’d really prefer not to have standard ssh access.
I’ve had a chat to our SA about this and he’s gonna see what he can do to reach out to the Session Manager team.
I can’t even find in the code where the session timeout is set. I think this could be a server side setting.
Ability to configure idle session timeout is now supported. Please refer to below documentations for more details.
In case of issues with active sessions getting disconnected forcibly, please provide us with some more information like sessionId, aws region, ssm agent logs etc to investigate this further. Thanks!
this has been launched:
https://docs.aws.amazon.com/systems-manager/latest/userguide/session-preferences-timeout.html
@DavidAtImpactCubed - kind of.
In my scenario (working for one of my clients), there was a confounding issue: Windows by default “unloads” the RDP GUI when minimised. My client was running automated testing software on a remote EC2 instance, with the RDP session minimised. Because Windows unloads the GUI, Session Manager saw no interaction (no keepalives) with the remote session and killed it once the timeout was reached. This halted the testing software in its tracks - it needed a live interactive session, to continue.
So part of the fix here was to add a registry key:
Additionally, I globally set the session timeout to 60 minutes, per the documentation.
I don’t know if this fixes your problem, but once I had made those two changes, SM stopped killing the port forwarding sessions. If necessary, you might need to use a (no-op) keepalive, to maintain your session? Note that multiple process can now share the same session (they couldn’t originally). So you could have two SSH sessions going through the same tunnel, one running a keepalive, the other doing your work.
Thanks for your feedback! We will look into this request.
@GNOMES There’s an internal feature request for this and I’m now on the list of customers interested in it, so when there’s an update I should hear more. You can probably get yourself added as well via your SA, account manager or possibly Support. If you have an NDA on your account you may also be able to get more information on timelines.