Skip to content


ContainerSSH 0.5: Everything but the Kitchen Sink

After a long slumber ContainerSSH is back with a brand new release! A tremendous amount of changes have been incorporated since the last release including multiple codebase refactors, a move to a monorepo setup for our internal modules and many long and highly requested features such as Oauth2, Kerberos authentication, port and connection forwarding and an advanced metadata handling system.

DevLog: SSH authentication via OAuth2

Traditionally, SSH supports authentication via a number of methods. Typically, you'd use passwords or SSH keys to log in. However, other methods are also possible: keyboard-interactive can be used to ask the connecting user a series of questions. This can be used for two factor authentication, for example. GSSAPI authentication allows for using Kerberos tokens obtained, for example, by logging into a Windows domain to be used as SSH credentials.

We broke your images 😢

Two days ago, on March 17, 2021 around 4:30 PM UTC we pushed a change to our build system that broke the container images we published on the Docker Hub. This change resulted in the following error when running the container:

Cannot start service containerssh: OCI runtime create failed: container_linux.go:349: starting container process caused "exec: \"/containerssh\": permission denied": unknown

To make matters worse, this did not only affect the most recent image, it broke all container images. The issue was reported an hour later and fixed on around noon UTC on the 18th of March, 2021.

If you are affected by this issue you can pull the fixed ContainerSSH image by pulling it:

docker pull containerssh/containerssh:<version>
podman pull containerssh/containerssh:<version>

Please set the imagePullPolicy in your pod spec to Always or switch to the image containerssh/containerssh:<version>-20200318

The <version> tag in this case should be replaced with your ContainerSSH version (e.g. 0.3.1).

Announcing the ContainerSSH Guest Agent

ContainerSSH is an integration project between the SSH library and the Docker and Kubernetes API. However, neither the Docker nor the Kubernetes API have been designed to host some of the more intricate SSH specific features.

For example, the Kubernetes "attach" API does not allow for retrieving the output of the command running in the container that happened before attaching reliably,and neither Docker nor Kubernetes allow sending signals to commands running in an "exec", etc.

The road to ContainerSSH 0.4: modularized structure, audit logging, and more

After a rapid rush of releases this summer we have announced that version 0.4.0 would have a long-awaited feature: detailed audit logging. This feature would allow for a forensic reconstruction of an SSH session. The use cases for this are diverse: from building honeypots to securing a corporate environment. We even published a preview release for test driving this feature. We even implemented an automatic upload for the audit logs to an S3-compatible object storage. So, what happened? Why isn't 0.4.0 released yet?