Skip to content

Authentication

ContainerSSH does not know your users and their passwords. Therefore, it calls out to a microservice that you have to provide. Your service can verify the users, passwords, and SSH keys. You will have to provide the microservice URL in the configuration.

Configuration

The authentication webhook can be configured in the main configuration using the following structure:

auth:
  <options>

The following options are supported:

Name Type Description
password bool Enable password authentication.
pubkey bool Enable public key authentication.
url string HTTP URL of the configuration server to call. Leaving this field empty disables the webhook.
timeout string Timeout for the webhook. Can be provided with time units (e.g. 6s), defaults to nanoseconds if provided without a time unit.
cacert string CA certificate in PEM format or filename that contains the CA certificate. This is field is required for https:// URL's on Windows because of Golang issue #16736
cert string Client certificate in PEM format or filename that contains the client certificate for x509 authentication with the configuration server.
key string Private key in PEM format or filename that contains the client certificate for x509 authentication with the configuration server.

Configuring TLS

TLS ensures that the connection between ContainerSSH and the configuration server cannot be intercepted using a Man-in-the-Mittle attack. We recommend checking the Mozilla Wiki for information about which configuration can be considered secure.

TLS version

The minimum TLS version for ContainerSSH 0.3 is 1.3. Server certificates must use Subject Alternative Names (SAN's) for proper server verification.

Client authentication

In order to safeguard secrets in the configuration the configuration server should be protected by either firewalling it appropriately, but it is better to use x509 client certificates as a means of authentication.

We recommend using cfssl for creating the CA infrastructure. First we need to create the CA certificates:

cat > ca-config.json <<EOF
{
  "signing": {
    "default": {
      "expiry": "8760h"
    },
    "profiles": {
      "containerssh": {
        "usages": ["signing", "key encipherment", "server auth", "client auth"],
        "expiry": "8760h"
      }
    }
  }
}
EOF

cat > ca-csr.json <<EOF
{
  "CN": "ContainerSSH CA",
  "key": {
    "algo": "rsa",
    "size": 4096
  },
  "names": [
    {
      "C": "Your Country Code",
      "L": "Your Locality",
      "O": "Your Company",
      "OU": "",
      "ST": "Your State"
    }
  ]
}
EOF

cfssl gencert -initca ca-csr.json | cfssljson -bare ca

The resulting ca.pem should be added as a client CA in your configuration server. This CA does not have to be the same used to sign the server certificate.

Then we can create the client certificate:

cat > containerssh-csr.json <<EOF
{
  "CN": "ContainerSSH",
  "key": {
    "algo": "rsa",
    "size": 2048
  },
  "names": [
    {
      "C": "Your Country Code",
      "L": "Your Locality",
      "O": "Your Company",
      "OU": "",
      "ST": "Your State"
    }
  ]
}
EOF

cfssl gencert \
  -ca=ca.pem \
  -ca-key=ca-key.pem \
  -config=ca-config.json \
  -profile=containerssh \
  containerssh-csr.json | cfssljson -bare containerssh

The resulting containerssh.pem and containerssh-key.pem should then be added to the configuration as client credentials:

configuration:
  cert: /path/to/containerssh.pem
  key: /path/to/containerssh-key.pem

The authentication webhook

The authentication webhook is a simple JSON POST request to which the server must respond with a JSON response.

Note

We have an OpenAPI document available for the authentication and configuration server. You can check the exact values available there, or use the OpenAPI document to generate parts of your server code.

Password authentication

On password authentication the authentication server will receive the following request to the /password endpoint:

{
    "username": "username",
    "remoteAddress": "127.0.0.1:1234",
    "sessionId": "An opaque ID for the SSH connection",
    "passwordBase64": "Base 64-encoded password"
}

Public key authentication

On public key authentication the authentication server will receive the following request to the /pubkey endpoint:

{
    "username": "username",
    "remoteAddress": "127.0.0.1:1234",
    "sessionId": "An opaque ID for the SSH connection",
    "publicKeyBase64": "Base64-encoded public key in the OpenSSH wire format"
}

The public key will be sent in the authorized key format.

Response

Both endpoints need to respond with an application/json response of the following content:

{
  "success": true
}