PrivX SSHExec Router
====================

The sshexec router type is used for controlling a router component using SSH
exec.

The sshexec router is configured with in network access manager settings with
a remote access client IP pool, SSH username and hostname, and router specific
parameter string. The SSH username and hostname are expected to match the host
account and host service address of the router, which has been deployed as a
host to PrivX. The parameter string is used for passing parameters to the
configuration commands. Network access manager does not interpret or use the
contents of the parameter string.

Network access manager executes the fixed commands
 /opt/privx/privx-router/sshexec/add {network parameters} {router parameters}
    {session parameters} [{static config}]
 /opt/privx/privx-router/sshexec/del {network parameters} {router parameters}
    {session parameters} [{static config}]
when adding or deleting PrivX router sessions. Both of these commands receive
network parameters, router parameters, session parameters and optionally
static config as a json encoded blob arguments:

Network parameters:
{
  "src": "10.0.0.1",
  "dst": [
    {
      "selector": {
        "ip": { "start": "192.168.1.1", "end": "192.168.1.1" },
        "proto": "tcp",
        "port": { "start": 443, "end": 443 }
      },
      "nat": { "addr": "192.168.57.19", "port": 10443 }
    }
  ],
  "src_nat": false,
}

Router parameters:
{
  "username": "ssh username",
  "hostname": "router hostname",
  "client_ip_pool": [ "10.0.0.0/24" ],
  "parameters": "router specific parameters configured in settings UI"
}

Session parameters:
{
  "session_id": "session UUID",
  "target_id": "network target UUID",
  "target_name": "network target name"
}

If network target's integration type is defined, static config parameters. While
this can be defined by the administrator, NQX integration, for example, will
have the following shape:
{
  "type": "l3rules",
  "source_id": "custom source UUID",
  "source_name": "custom source name"
}

The add / del commands are expected to return zero exit code on success and
non-zero exit code on failure.

The add / del command is expected to output a json blob with arrays of
commands for adding / deleting the session to router and for rolling back the
changes on failure:

{
  "commands": [
    {
      "string": "command to add / del session",
      "rollback_command": "command for rolling back changes made by this command"
    }
  ]
}

The del command is expected to output a similar json blob but the
rollback_commands are not used.

After successfully executing the add / del command the network access manager
then executes returned commands in the returned order in separate ssh exec
requests for each command. If execution of a command fails then network
access manager executes the rollback commands (if there is one)
for each command that was already executed in reversed order.
