Close
logodocs

strongDM Sidecar Connector

The portal script connects to a strongDM listener running in sidecar mode and tunnels localhost ports through the sidecar via SSH. It periodically scans for changes in the sidecar, and it automatically reopens connections if a network partition happens.

Basic (Unauthenticated) Use

On the sidecar server, start the listener with:

sidecar$ sdm sidecar --addr=$IP:$PORT

Set $IP to the listening IP address of the sidecar, and $PORT to the port you wish to run the sidecar listener on.

On the main server, start the portal script:

main$ SDM_SIDECAR_HOST=$IP SDM_SIDECAR_PORT=$PORT python portal.py

Ensure $IP and $PORT are the same as above.

Once connected, the sidecar and script will automatically map over any datasource and server ports that are connected in the strongDM client. You can manually connect/disconnect datasources and servers on the sidecar server.

strongDM recommends using a service account with Auto-Connect Service Accounts? turned on in the admin UI. This will ensure that the sidecar and script automatically map all available datasources and servers as soon as the connection is brought up. However, the setup will also work fine with a normal strongDM user and manual datasource connection.

Adding Authentication

The portal script uses the locally configured ssh to talk to the sidecar server. You may want to extend this configuration with ssh_config. If you want to be sure that the sidecar only accepts connections from the right server, you may use a public key to authorize access:

On the sidecar server:

sidecar$ export AUTHORIZED_KEY="ssh-rsa AAAA...qI/ user@example.com"
sidecar$ sdm sidecar --addr=$IP:$PORT --pubkey="$AUTHORIZED_KEY"

On the main server:

main$ cat >> /etc/ssh_config
Host $SDM_SIDECAR_HOST:$SDM_SIDECAR_PORT
IdentityFile specific-identity.pem

By default, the portal script does not validate the host key of the sidecar. This means that the main server could unknowingly connect to a malicious sidecar. To enable host key verification, make sure the sidecar's host key exists in ~/.ssh/known_hosts on the main server. You can do this by manually ssh'ing from the main server to the sidecar and entering "yes" for the host key verification prompt. Then set the SDM_SIDECAR_STRICT environment variable to yes when running the portal script, like so: main$ SDM_SIDECAR_STRICT=yes SDM_SIDECAR_HOST=$IP SDM_SIDECAR_PORT=$PORT python portal.py.

Lifecycle

SSH connection: available
┌─────────┐ listening ports ┌─────────┐
│ ├───────────────────────▶│ │
│ │ │ │
│ Solaris │ SSH forwarded ports │ Linux │
│ Main Server │◀──────────────────────▶│ SDM Listener │
│ │◀──────────────────────▶│ │
│ │◀──────────────────────▶│ │
└─────────┘ └─────────┘

The main server has a main loop comprised of three steps:

  1. Load state: The SDM listener uses the state tree to return a comma-separated list of available forwarded ports. It is a direct reaction to the regular SDM commands (sdm connect, sdm disconnect, sdm status, etc.)
  2. Update port forwarding: For the new ports, the main server invokes SSH to do local port forwarding (ssh -L -N) to the sidecar. For ports that are no longer available, the main server terminates the respective SSH process.
  3. Wait one second: The main server can take up to roughly one second to respond to state changes. This means that any automation scripts relying on the portal should wait for the update cycle to complete before making progress.