You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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
A configurable signal should be sent to the container's PID 1
ContainerSSH should wait a configurable amount of time to allow for a graceful shutdown or for the user to exit
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:
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
A configurable signal should be sent to the container's PID 1
Should the user react, i.e. we see traversal of stdin/stdout/stderr, the idle timeout is reset
Should the user not react, a configurable signal should be sent to the container's PID 1
ContainerSSH should wait a configurable amount of time to allow for a graceful shutdown or for the user to exit
After the configurable grace period is up, a SIGKILL should be sent or the container simply shutdown and removed as usual
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.
The text was updated successfully, but these errors were encountered:
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:
Once the idle timeout has been reached, i.e. no stdin/stdout/stderr:
Here is an example config I imagine:
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.
The text was updated successfully, but these errors were encountered: