Use the Okta Privileged Access client
Every Okta Privileged Access client command uses the syntax:
sft [global options] command [command options] [arguments...]
You can use the following options with any client command:
- -h, --help: Displays help.
- -v, --version: Displays version.
|Gets and sets client configuration options. See Configure the client.
|Opens your team's dashboard in your browser.
|Shows your client's device info as JSON.
|Adds your new client to your client inventory on the Okta Privileged Access platform.
|sft fleet enrolls
|Silently enroll clients multiple clients within a fleet. See Silently enroll the Okta Privileged Access client.
|Shows a list of commands or help for one command.
|Lists the accounts that this client is configured to use.
|Lists available projects for the team.
|Lists the servers available in the current team.
|Lists the servers available in the current team in an RJSON format. You can save this output to a file and used in Royal TSX to create a dynamic folder. See Configure Royal TSX for Okta Privileged Access.
|If logged out of your client's current team, creates a session, authenticating with your team's Identity Provider.
An active, authorized client session allows the Okta Privileged Access client to request credentials in the background as needed.
|Logs out from the current session.
|Used with OpenSSH ProxyCommand to enable transparent use of sft with ssh, scp, rsync, ftp, and so on.
|Connects through RDP to a target passed as an argument.
(Windows only) Opens the ScaleFT application when a user clicks the Connect button on the My Servers page.
For this to work correctly, you must update the Windows Registry with the following entry: Computer\HKEY_CLASSES_ROOT\ScaleFTProtocolHandler\shell\open\command.
The ScaleFT application can't be launched by the Connect button if the corresponding entry is missing from the Windows Registry.
|Resolves a single-server matching the specified hostname or instance-details.
|Lists all available secrets commands.
|sft secrets list
|Lists all top-level secret folders and secrets.
You must provide both --project and --resource-group parameters or exclude them completely.
|sft secrets create
|Creates a secret.
|sft secrets create-folder
|Creates a secret folder.
|sft secrets describe
|Shows metadata about the secret at path.
|sft secrets describe-folder
|Shows metadata about the secret folder at path.
Updates a secret’s values.
Use update-secret-metadata to update a secret’s name or description.
|sft secrets delete
|Deletes the specified secret.
|sft secrets delete-folder
|Deletes the specified secret folder. All the contents in that folder is also deleted.
|sft secrets reveal
|Displays the key names and secret value fields.
|Updates the name or description of a secret.
|Updates the name or description of a secret folder.
|sft session-logs verify
|Verify the integrity of a specified session log against the Okta Privileged Access gateway signing key registered with Okta Privileged Access. Log files without valid signatures may be inaccurate or corrupted by an attacker.
|sft session-logs export
|Export session logs to a particular format. By default, logs are exported to JSON format. Session logs are also verified during the export process. Log files without valid signatures may be inaccurate or corrupted by an attacker.
|Connects through Secure Shell to a target passed as an argument.
Generally, Okta Privileged Access works with ssh using OpenSSH ProxyCommand integration. The sft ssh command is provided for ssh support in environments or contexts where OpenSSH isn't available. The command can also be used when you want to explicitly pass Okta Privileged Access-specific options such as --via.
|Prints an OpenSSH configuration block suitable for use in your ~/.ssh/config file, which enables your local ssh binary to use Okta Privileged Access authentication. This SSH configuration is used only when your client has a currently active and authorized session.
|sft support collect
|Collect local diagnostic information for Okta Support.
|sft support submit
|Submit diagnostic information for Okta Support.
|Removes the currently active client from your client inventory in the Okta Privileged Access platform.
|Sets an enrolled team as the current default for use in your current session.
-l, --selector: The selector (label query) to filter on.
Commands that take a selector as an optional argument can filter their results based on an arbitrary selector query.
The selector syntax is based on Kubernetes label queries. See Labels and Selectors.
sft list-servers -l os_type=windows,project_name=Demo
The example uses a selector to filter the list of servers you have access to. It returns a list of Windows servers that are enrolled in the demo project.
You can view or set configuration options with the sft config command.
No configuration file exists when the Okta Privileged Access client is installed. The configuration file is created when you set your first configuration option.
Default settings are used until you explicitly set a configuration value. The defaults provided for the Okta Privileged Access client are intended to provide the most security and ease of use for the most common situations. Aside from personal preferences, such as the setting for rdp.screensize, you may not need to set any client configurations at all.
Okta Privileged Access client configurations are grouped into sections. Currently these sections include rdp, ssh, ssh_agent, service_auth, and update.
View your configuration
- sft config: Display your current configurations.
- sft config [section.key]: View the current value of a specific configuration indicated by section.key
Set a configuration value
You can set a configuration value with the command syntax: sft config [section.key] [value].
|Set this to a string value, such as 1024x768 that describes your preferred RDP window size.
|sft config rdp.screensize 800x600 sft config rdp.screensize 1024x768
|Set this to true to have RDP sessions open in fullscreen mode. When set to true, the value of rdp.screensize is ignored.
|sft config rdp.fullscreen true sft config rdp.fullscreen false
|(macOS only) Set this to your preferred RDP client, either royaltsx for Royal TSX, or macfreerdp for MacFreeRDP. If this option isn't set, Okta Privileged Access attempts to use Royal TSX, and then MacFreeRDP if Royal TSX is unavailable.
|sft config rdp.client royaltsx sft config rdp.client macfreerdp
|If set to true, the Okta Privileged Access client stores any passphrases entered by the user in the workstation's local cryptographic store.
|sft config ssh.save_privatekey_passwords true sft config ssh.save_privatekey_passwords false
|Set this to netcat to have Okta Privileged Access remotely execute netcat (nc) as a means of port forwarding, rather than using the default native SSH port forwarding.
|sft config ssh.port_forward_method netcat sft config ssh.port_forward_method native
This feature is not compatible with the Windows client.
Set this to host to set the ForwardAgent when executing SSH commands. SSH credentials issued by Okta Privileged Access aren't added to the ssh-agent. This option is used for hosts configured to accept externally managed credentials such as SSH public keys not managed by Okta Privileged Access.
Not setting this option or setting it to the value none causes Okta Privileged Access to not forward the SSH agent.
|sft config ssh.insecure_forward_agent host sft config ssh.insecure_forward_agent none
|If set to true, the Okta Privileged Access client uses an SSH agent when authenticating.
|sft config ssh_agent.enable true sft config ssh_agent.enable false
Set this to a JSON array of one or more paths to SSH private keys to load into the SSH agent. You can append values to this list by using the --append flag.
Tip: When writing a JSON literal in Windows PowerShell, escape inner quotes; for example:
sft config ssh_agent.keys '[\"C:\\Users\\alice\\.ssh\\id_rsa\"]'
|sft config ssh_agent.keys '["/Users/alice/.ssh/id_rsa"]' sft config ssh_agent.keys --append /Users/alice.ssh/id_rsa sft config ssh_agent.keys ''
|If you configure this option, the Okta Privileged Access client uses the specified HTTP or HTTPS URL as an HTTP tunnel.
|sft config network.forward_proxy https://your-proxy.example.com:3141
If set to true, the Okta Privileged Access client uses a bundled CA certificate list for TLS validation. Similarly, if set to false, the client uses the operating system's CA list.
This option is enabled by default. Okta recommends not to disable it, as certain operating systems may have issues with CA lists and the performance may be worse than using bundled CA certificate lists.
|sft config network.tls_use_bundled_cas true sft config network.tls_use_bundled_cas false
|If set to true, the Okta Privileged Access client supports authentication for service users. See Service users.
|sft config service_auth.enable true sft config service_auth.enable false
|The Okta Privileged Access client defaults to the stable update channel, but you can opt into receiving more frequent releases by setting this option to use the test update channel.
|sft config update.release_channel test sft config update.release_channel stable
Defines the maximum time that the client waits for a response from a server before resending the request.
|sft config client.timeout_seconds 60 sft config client.timeout_seconds -1
|When set, any command run prints internal logs and timing messages to
|SFT_DEBUG=1 sft list-servers
|When set, allows connections with usernames that include non-standard characters.
|SFT_ALLOW_INSECURE_USERNAMES=1 sft ssh ...
If you enable the SFT keyring, all of the plaintext tokens in the state.json file are encrypted. Once the SFT keyring is established on a system, it automatically updates when the user logs in to Okta Privileged Access or attempts to access a server.
After the SFT keyring is activated, it can't be reversed. Okta Privileged Access employs the compat keyring for all operating systems, which doesn't offer encryption. To revert to the default compat keyring, users need to re-enroll and relogin.
Before you begin
- SFT keyring encrypts access tokens. If the keys used to decrypt the tokens are unavailable, decryption is impossible. This prevents unauthorized data exfiltration.
- SFT keyring on Linux uses D-Bus to connect to a desktop-specific SecretService and proactively secures access tokens. If sft can't reach an unlocked SecretService, it will not be able to decrypt those tokens. This may result in being locked out of your tokens while in non-desktop mode if you use Linux on both desktop and non-desktop. To avoid this, you can use the insecure compact keyring by setting SFT_KEYRING to compat in your shell initialization scripts and then re-enrol.
Setting up the Keyring
SFT keyring must be configured on every device. The operating system comes with a default keyring, and it determines the most suitable one to use. By using the system variable in the configuration, the operating system automatically selects the optimal keyring for use.
SFT keyring encrypts by default on macOS. You can set the keyring using the User Defaults framework:
$ defaults write com.scaleft.ScaleFT SFTKeyring system
Alternatively, you can enable it by setting an environment variable:
If both are set, the environment variable takes precedence.
To disable encryption, use compat instead of system in the environment variable, and then re-enroll in the team.
SFT keyring encrypts by default on Windows. You can set the keyring using the registry:
Alternatively, you can set the keyring using the SFT_KEYRING environment variable.
HKEY_LOCAL_MACHINE takes precedence over both the environment variable and CURRENT_USER entry. The environment variable takes precedence over the CURRENT_USER entry.
To disable encryption, set the registry key to compat instead of system, and then re-enroll in the team.
FreeBSD / Linux
In FreeBSD and Linux, keyrings only work in a D-Bus desktop environment. In Linux, the default encryption method is system, while in FreeBSD, it's compat.
To set or update the SFT_KEYRING environment variable to either compat or system, add the following to the shell profile: