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:

auth:
  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
}