To create a host-deployment script, navigate to the Settings→Deployment→Deploy and configure SSH target hosts page, select Configure using a deployment script, then click Add Script. Download the deploy.py script when prompted to.

Execute the deployment script on the target host as root. You will at least need to provide the host type, and the principals (specifying which target accounts can be accessed, and by whom).

To specify the host type, use one of the following options:

To specify principals, use any of the following options:

For example, using --personal-account-roles to allow members of the roles Example Role 01 and Example Role 02 to log in with their personal accounts, add:

--personal-account-roles "Example Role 01,Example Role 02"

You may also specify --principals to define target accounts and the roles that may access them. The general format is:

--principals target_account1=role1,role2,…:target_account2=role3,role4,…:… 

For example, to allow target account alice to be accessed by PrivX users belonging to the privx-admin role, set this option to:

--principals alice=privx-admin

As another example, to additionally allow accounts alice and bob to be accessed by members of Example Role:

--principals alice=privx-admin,"Example Role":bob="Example Role"

Full syntax example of running the host-deployment script:

# /path/to/deploy.py --standalone \
--personal-account-roles "Example Role 01, Example Role 02" \
--principals alice="Example Role",privx-admin:bob=privx-admin

For a full list of options supported by the host-deployment-script, run:

$ /path/to/deploy.py help

# /path/to/deploy.py --standalone \
--personal-account-roles "Example Role 01" \
--api-hostname "extender.example.com:8443"

# openssl x509 -text -noout -in \
/opt/privx/extender/extender.crt | grep -A 1 \
"Subject Alternative Name"

Certificates issued by PrivX are very time-sensitive. Even a clock skew of few minutes may prevent certificates from working correctly.

Verify that the target-host time is correct. Adjust as necessary.

Ensure the system clocks are synchronized (for example, using NTP). The certificates issued by PrivX have very short validity periods: clock skew may cause authentication to fail.

The SSH server on the target host must be configured to trust certificates issued by PrivX (PrivX Administrator Manual > Authentication Methods for Host Connections > Enabling Certificate-Based Authentication for SSH Connections > Manual Certificate-Authentication Setup > Trusting PrivX Certificates).

For target user accounts, specify the principals that are allowed to connect. Depending on the target-host OpenSSH version, you can do this in either of the following methods:

To display the target hosts and accounts under known targets in PrivX, add the host to PrivX (PrivX Administrator Manual > Establishing and Managing Connections > Setting up Known Targets).

On the Settings→Hosts page, Edit the target RDP server.

Under the RDP host certificate section, click

Upon next RDP connection, PrivX automatically accepts the new RDP-server certificate for subsequent RDP connections.

Modify the RDP proxy settings, located at the following path on your PrivX servers:

/opt/privx/etc/rdp-proxy.toml

Locate and modify the following settings:

These two settings are cumulative. For example, to allow the RDP-server certificate to be renewed from two months and 15 days before the current one expires:

[certificates]
update_automatically = true
renewal_period_months = 2
renewal_period_days = 15

Save your changes to the RDP-proxy configuration.

Restart the PrivX services to apply the new settings:

# systemctl restart privx

In your AWS management interface, create an IAM user for obtaining AWS roles. To do this, provide the AWS user with the following permission policies:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "sts:GetFederationToken",
            "Resource": [ "*" ]
        },
        {
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Resource": [ "*" ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "iam:ListRoles",
                "iam:ListAttachedRolePolicies",
                "iam:GetPolicy",
                "iam:GetPolicyVersion",
                "iam:ListPolicies",
                "iam:ListPolicyVersions",
                "ec2:DescribeInstances",
                "ec2:DescribeRegions"
            ],
            "Resource": [ "*" ]
        }
    ]
}

PrivX uses this AWS user to import and delegate AWS roles. For this reason you must also create a Secret Access Key for the user. Copy the Access Key ID and the Secret Access Key of the user, which are required later for configuring PrivX.

In your AWS management interface, create AWS role(s) that grant access to AWS services. The AWS role(s) should have permissions like the following (replace the example Actions with services and actions this role should allow access to):

{
    "Version": "2012-10-17",
    "Statement": [
       {
            "Effect": "Allow",
            "Action": [
                "s3:Get*","s3:List*"
            ],
            "Resource": [ "*" ]
        }
    ]
}

Also set the trust relationships of the AWS role similar to the following (replace <iam_user_arn> with the ARN of the previously-created IAM user):

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "<iam_user_arn>"
            },
            "Action": "sts:AssumeRole",
            "Condition": {}
        }
    ]
}

On the Settings→Directories page of the PrivX GUI, add a directory of the type Amazon Web Services. Provide the Access key ID and Secret Access Key of the previously-created IAM user.

Also under Advanced AWS settings, select Enable AWS role federation. If you only want to import roles under a certain path, set this path to AWS role prefix for federated roles

Save the directory configuration. To verify that roles were imported successfully, ensure that the previously-configured AWS roles are visible on the page Settings→Deployment→Configure Amazon Web Service role grants.

Grant AWS roles to PrivX roles. To do this, go to the page Settings→Deployment→Configure Amazon Web Service role grants, and Edit the AWS roles. PrivX users belonging to specified roles can now gain access according to any AWS roles granted to them.

Log into the CLI account on your workstation, activate the PrivX agent if necessary.

Use the PrivX agent to log into PrivX (replace username with your PrivX-user name):

$ privx-agent-ctl login username

Determine and assume an AWS role available for your account (replace example_aws_role with the name of the role you want to assume):

$ privx-agent-ctl aws-role list

$ privx-agent-ctl aws-role set example_aws_role

You may verify that you have successfully assumed the role by listing the AWS roles. It should be marked with an asterisk (*). For example:

$ privx-agent-ctl aws-role list
Available AWS roles:
  example_aws_role_0
 *example_aws_role
  example_ws_role_2
  ...

You are now permitted to run any AWS services permitted by the AWS role. For example, if the AWS role gives you read access to the s3 service, you can now run:

$ aws s3 ls s3://bucket.example.com/