Support overall session timeout and idle timeout

[William E Little Jr]

Please describe what you would like to see in ContainerSSH

As a security measure, I would like the option to limit the overall session time and the time which a client may sit idle, i.e. no stdin/stdout/stderr. After these timeouts are reached, the user would need to log out/in or re-authenticate

Once the session timeout has been reached:

1. Optionally, a configurable warning/banner should appear in the clients PTY. Should no warning/banner be configured, only the signal should be sent, i.e. it is the application's responsibility to properly warn the client
2. A configurable signal should be sent to the container's PID 1
3. ContainerSSH should wait a configurable amount of time to allow for a graceful shutdown or for the user to exit
4. After the configurable grace period is up, a SIGKILL should be sent or the container simply shutdown and removed as usual

Once the idle timeout has been reached, i.e. no stdin/stdout/stderr:

1. Optionally, a configurable warning/banner should appear in the clients PTY. Should no warning/banner be configured, only the signal should be sent, i.e. it is the application's responsibility to properly warn the client
2. A configurable signal should be sent to the container's PID 1
3. Should the user react, i.e. we see traversal of stdin/stdout/stderr, the idle timeout is reset
4. Should the user not react, a configurable signal should be sent to the container's PID 1
5. ContainerSSH should wait a configurable amount of time to allow for a graceful shutdown or for the user to exit
6. After the configurable grace period is up, a SIGKILL should be sent or the container simply shutdown and removed as usual

Here is an example config I imagine:

ssh:
  timeouts:
    idle: 
      timeout: 1h
      signal: SIGUSR1
      grace: 30s
      banner: |
        ********************************************************
        * Idle Timeout Reached; React in 30s to avoid shutdown *
        ********************************************************
    session:
      timeout: 12h
      signal: SIGTERM
      grace: 1m
      banner: |
        *******************************************
        * Session Timeout Reached; Shutdown in 1m *
        *******************************************

Please describe your use case

I maintain a legacy SSH bastion service, primarily for Business-to-Business and Business-to-Consumer connections. Since these connections are to servers owned by other entities, there is a heightened legal risk, compared to using this to access our own infrastructure. Our legacy service provides support agents with secure access to client servers, without divulging credentials to the support agent, among other features like auditing. ContainerSSH makes this extremely easy; I simply craft a container with our captive-shell as the entrypoint and inject secrets via the authconfig service. So I am replacing aspects of the legacy service with ContainerSSH.

One of the security features of the legacy system are these session and idle timeouts. We view the connection to this bastion service as privileged, and in our view, allowing for session timeouts is similar to using short-lived secrets.

Our stakeholders would like to limit risk of support agent's logging into a client server and leaving an unattended terminal open. As well, should support agent's credentials be compromised, a session timeout forces re-authentication, which can help remove footholds. I believe the same could be said about off-boarding support agents. Ideally off-boarding or revoking of privileges is instant; however, in practice, this is not always the case with larger enterprises who have a sprawl of systems. Enforcing a session timeout can help us better close those gaps in automation or manual off-boarding processes.

As an example, our support agents work 8 hr/day on average, so our session timeout is configured at 12 hours. In a normal scenario, the support agent never encounter's it; however, if they leave their computer logged in overnight, or perhaps they simply never exit their shells and only open new tabs/windows 😅. The timeouts are good security hygiene/housekeeping.

[William E Little Jr]

Also, wanted to say thank you for the awesome project!