Skip to content

Blog

  • 2 min read

ContainerSSH 0.6: Persistent Pods

ContainerSSH 0.6 has been released! This release introduces the persistent Kubernetes execution mode, extra scope support for OIDC authentication, important bug fixes for Kerberos and Docker image pulling, and a lot of dependency updates.

Change summary

  1. Persistent Kubernetes execution mode
  2. OIDC extra scopes
  3. Kerberos authentication fixes
  4. Docker image pull policy fix

Persistent Kubernetes execution mode

A new persistent execution mode has been added to the Kubernetes backend. Unlike the existing connection mode which create a new pod for each SSH connection and terminates the pod after the session terminates, persistent mode execs into an already existing pod with an option to create the pod if it doesn't exist, or to simply refuse entry if it doesn't. This mode can be useful for use-cases where stateful sessions are needed, including but not limited to managing long-running interactive processes, resource sharing etc.

ContainerSSH cannot guarantee user isolation in this mode

It is expeced that the users of this feature will use the configuration server to ensure that every user is dropped into the correct pod, ideally unique per-user. Do not specify the pod to use in the global configuration as this will lead to all users to be sent to the same pod without any isolation. If this is combined with any type of credential forwarding it can lead to the users credentials being compromised.

In the simplest form the persistent mode can be configured with the following block:

kubernetes:
  pod:
    mode: persistent
    metadata:
      name: my-existing-pod
      namespace: default

With the createMissingPods option a minimal pod spec is also required:

kubernetes:
  pod:
    mode: persistent
    createMissingPods: true
    metadata:
      name: my-pod
      namespace: default
    spec:
      containers:
        - name: shell
          image: containerssh/containerssh-guest-image

Thanks to @gigabyte132 for contributing this feature.

Read more »

OIDC extra scopes

The OIDC authentication provider now supports requesting additional scopes beyond the default openid scope.

Two new configuration options have been added for the oidc provider:

  • extraScopes: A list of additional OIDC scopes to request during authentication.
  • enforceScopes: When set to true, authentication will be rejected if the user does not grant all requested extra scopes.
auth:
  keyboardInteractive:
    method: oauth2
    oauth2:
      provider: oidc
      oidc:
        url: https://your-oidc-server.example.com/
        extraScopes:
          - profile
          - email
        enforceScopes: true

These options work with both the device flow and authorization code flow.

Thanks to @hashkrish for contributing this feature.

Read more »

Kerberos authentication fixes

This release fixes two issues with Kerberos authentication:

  • enforceUsername=false now works correctly. Previously, disabling username enforcement would still reject valid logins with differing usernames.
  • Metadata merging is now additive. Kerberos authentication metadata is now correctly merged with existing connection metadata instead of replacing it. This ensures that metadata set by earlier authentication or configuration steps is preserved.

Thanks to @gigabyte132 for contributing this feature.

Docker image pull policy fix

The behavior of the IfNotPresent image pull policy has been corrected. Previously, images with no tag or the :latest tag were always pulled even when already present locally, which prevented using local images. The IfNotPresent policy now consistently skips pulling when the image is already available locally, regardless of the tag.

Thanks to @AlbertoPimpo for the fix

  • 5 min read

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.

  • 3 min read

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.

  • 4 min read

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).

  • 2 min read

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.

  • 2 min read

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?