ScaleFT implements a custom name resolution system, which is used to resolve user-supplied names to a server registered with ScaleFT.
For example, if you run
sft ssh web0, the name
web0 will be resolved in ScaleFT. Likewise, if the agent on
web0 has a config file specifying
bastion.example.com will be resolved in order to establish a tunnel to
If ScaleFT is unable to resolve a name to an enrolled server, ScaleFT will fall back to using locally supported name resolution and authentication methods to access the server. For example, if you run
sft ssh web0.example.com and ScaleFT is unable to resolve that name to a server enrolled in ScaleFT, the client will behave as though you had run
ssh web0.example.com without using ScaleFT at all.
ScaleFT only matches names against active servers. A server is considered active if all of the following conditions are true:
As a special case, if an Unmanaged Server is created in ScaleFT it will be considered active until it is deleted.
When resolving a name, ScaleFT will look for any server matching one of the following values.
id, a random UUID automatically assigned by the ScaleFT platform during enrollment.
hostname, as reported by the operating system on the server. If the OS hostname ends in “.local” this will be ignored by the platform. For example, if the OS hostname is “web0.local”, you will be able to access the server as “web0”, but not as “web0.local”.
CanonicalName value is specified in the ScaleFT agent config, this value will be used in place of the OS hostname.
AltNames values specified in the ScaleFT agent config file on the server. AltNames can be used to add additional aliases to servers.
The default IP address of the server, as determined by ScaleFT.
If the server is an AWS or GCE cloud instance, the provider-assigned ID of the instance.
If a name supplied to the ScaleFT client resolves to more than one server the client will return an error in order to avoid inadvertently connecting to an unintended server.
One side effect of this is that if a server is replaced with a new server bearing the same hostname, or if the agent is forced to re-enroll, a user with administrative privileges will need to manually delete the original server record before the new one can be addressed by the shared name. Alternatively, users can specify an unambiguous name such as the server ID, or wait for the original server record to become inactive.
Bastion name supplied in a ScaleFT agent configuration is ambiguous, the ScaleFT platform will attempt to choose the best fit by ranking matches in descending order of preference by matching:
Ties are broken arbitrarily.
Once a server has been resolved, ScaleFT will attempt to determine the IP address that should be used to address it.
If the server is being accessed directly by the ScaleFT client, the client will attempt to use the server’s Default IP Address as described below.
If the server is being accessed via one or more bastions, and the immediately preceding bastion resides in the same AWS VPC or GCE Network as the server, ScaleFT will prefer the server’s corresponding private IP address. Otherwise ScaleFT will use the Default IP Address.
Each server enrolled in ScaleFT is assigned a Default IP Address, which will be the first available value from:
AccessAddressvalue specified in the ScaleFT agent configuration file
public_ip_v4based on the instance metadata