Custom SSH configurations for clients
Advanced Server Access allows SSH customization options for both Advanced Server Access admins and their teams. End users can adjust how their client responds when attempting SSH connections, and admins can
customize how their servers respond to clients initiating connections. Before beginning, make sure that you've installed the ScaleFT ClientEssentially, a client is anything that talks to the Okta service. Within the traditional client-server model, Okta is the server. The client might be an agent, an Okta mobile app, or a browser plugin. and run the
sft ssh-config command.
Note: Any paths provided are from a MacOS perspective and use
/Users/Admin/ as an example folder path. Paths on your machine may read differently.
Depending on your Advanced Server Access client and your SSH configuration, you should see something like the following within your config file:# To use ScaleFT proxycommand, add this configuration block to your $HOME/.ssh/config
Match exec "/usr/local/bin/sft resolve -q %h"
ProxyCommand "/usr/local/bin/sft" proxycommand %h
UserKnownHostsFile "/Users/AdminAn abbreviation of administrator. This is the individual(s) who have access to the Okta Administrator Dashboard. They control the provisioning and deprovisioning of end users, the assigning of apps, the resetting of passwords, and the overall end user experience. Only administrators have the Administration button on the upper right side of the My Applications page./Library/Application Support/ScaleFT/proxycommand_known_hosts"
-qstands for "quiet", meaning that any issues that occur while connecting to your target severs will not be shown to the user or provoke a reaction from your client. This includes the state where you are not logged in. In that event, with
-q, your SSH command will fail to find the host and you will not be authorized to access the host inventory in Advanced Server Access. Removing
Match execline of your config file results in your client sending a browser log in request to the Advanced Server Access Platform after an SSH attempt fails.
Matchdirectives allow the user to control specific client behavior for each server within their team. By identifying potential target servers through a customized
Matchdirective, users can than incorporate other customization options (such as removing
-q) to allow their client to take certain actions when trying to connect to a specific server.
For example, this is a
Matchblock that could be added to your config file:
Match Host *ubu* "/usr/local/bin/sft resolve -q %h" ProxyCommand "/usr/local/bin/sft" proxycommand %h UserKnownHostsFile "/Users/Admin/Library/Application Support/ScaleFT/proxycommand_known_hosts"
This creates a scenario where any attempted connections to servers that have names containing the letters "ubu" will follow the rules listed in this
Identifying specific bastions to connect through
Another customization option is to, instead of configuring a bastion via the agent configuration file
sftd.yaml, dictate to your client specific bastions it needs to move through dynamically when attempting SSH connections. This is done through the
--viacommand, which can be added to the ProxyCommand lines of your config file as such:
ProxyCommand "/usr/local/bin/sft" proxycommand --via <bastion> %h
Note: The name
<bastion>is used as a placeholder for one of your teams bastions, so modify this as needed.