Discovering authorized SSH keys using sshd_config

The SSH server configuration file (sshd_config) can be used to discover and identify SSH authorized keys on network server. The contents of the sshd_config file are also visible in SSH Manager for Machines for devices that use agentless discovery. Administrators can view the contents of sshd_config (on agentless devices) without the need to access the box directly.

Trust Protection Foundation reads the sshd_config file to determine the paths used to locate authorized keys. Based on those paths, it then discovers the public keys that are authorized to access the device.

Format of the sshd_config file

The sshd_config file follows the OpenSSH standard. One of the directives in this file specifies where the SSH server looks for authorized public keys. For more information about configuring the sshd_config file, see the manual page for sshd_config.

Location of the AuthorizedKeysFile configuration option

The AuthorizedKeysFile configuration option in /etc/ssh/sshd_config specifies where the SSH server looks for authorized keys. The option may contain more than one location, separated by spaces.

The AuthorizedKeysFile option may include variables that Trust Protection Foundation expands dynamically by querying the system’s user database (for example, local user records or directory‑based identity sources). This allows discovery to correctly resolve each user’s actual home directory, even in heterogeneous environments.

Variable	Description	Example	Exceptions
%%	Replaced by a literal %
%h	Replaced by the actual home directory of the user being authenticated, as defined by the operating system or directory service.	If user jane has a home directory at `/local/home/jane`, then `%h/.ssh/authorized_keys` resolves `to /local/home/jane/.ssh/authorized_keys`.	Resolution depends on values returned by the system user database.
%u	Replaced by the login name of the user	`/var/ssh/%u/ak` resolves to `/var/ssh/jane/ak` for user jane.

Path expansion rules

After variable expansion, Trust Protection Foundation evaluates the resulting path using OpenSSH path semantics.

Absolute paths. If the expanded path begins with a /, it is treated as an absolute path (for example, /etc/ssh/keys/%u).
Relative paths. If the expanded path does not begin with a /, it is treated as relative to the user’s home directory (for example, .ssh/authorized_keys).

If the AuthorizedKeysFile option is not present, or is blank, Trust Protection Foundation uses the default OpenSSH key locations.

.ssh/authorized_keys
.ssh/authorized_keys2

Supported and unsupported values

Trust Protection Foundation supports a wide range of AuthorizedKeysFile configurations to accommodate real-world environments.

Supported configurations

Multiple locations. If the AuthorizedKeysFile option specifies multiple locations separated by spaces, all specified locations are scanned.
Custom paths and patterns. Patterns such as .ssh/keys, %h/.ssh/authorized_keys, or /secret/%u/authorized_keys are supported.
Fallback behavior. If the system user database cannot return a home directory for a specific user, discovery logs the issue and falls back to standard default locations to allow the discovery job to continue.

Unsupported configurations

Multiple variables in the same parameter. For example, %h/%u/.ssh is not supported.
Match blocks. The Match keyword is not supported. Any AuthorizedKeysFile parameters defined inside a Match block are ignored.

What kinds of public keys does SSH Manager for Machines support?

SSH Manager for Machines recognizes the following types of public keys:

Authorized keys. Public keys stored in a location that matches an expanded AuthorizedKeysFile directive. This includes keys discovered in dynamically resolved home directories.
Known host keys. Public keys stored in known_hosts files that allow a client to verify the identity of a server.
Idle Public keys. Public keys found during discovery that are not located in a recognized authorized keys file or a known‑hosts file. Because Trust Protection Foundation now resolves dynamic home directories, keys that were previously misclassified as idle in non‑standard home locations (such as /export/home) are now correctly identified as Authorized when appropriate.

Refer to the table below to see how the authorized keys and known host keys are used in a network setup like the one pictured.

Device	Key type	Description
A	Known host key	Stores machine B's public key in a `known-hosts` file.
B	Authorized key	Stores machine A's public key in an `authorized_keys` file.
B	Known host key	Stores machine C's public key in a `known-hosts` file.
C	Authorized key	Stores machine B's public key in an `authorized_keys` file.

As you can see, the key type is a function of the direction of the connection. The client, or machine initiating the connection has the server's public key in a known-hosts file. The server stores the client's public key in an authorized-keys file.

A machine can be both a client and a host. It is a client when it initiates a connection to another device. It is a host when it receives an incoming connection request.

Working with the sshd_config file

Trust Protection Foundation looks for the sshd_config file in the following location:

/etc/ssh/sshd_config

If the file is not found, discovery logs an error and uses the default authorized keys locations.

When using agent‑based discovery, Trust Protection Foundation does not have direct access to the sshd_config file, so the file contents cannot be displayed. When using agentless discovery, the file is processed as part of discovery and can be viewed in SSH Manager for Machines.

How does the sshd_config file work?

The SSH server reads configuration data from the config file. The file contains keyword-argument pairs, one per line. Lines starting with the hash symbol # This line is a comment and empty lines are interpreted as comments. Arguments may optionally be enclosed in double quotes "argument with space" in order to represent arguments containing spaces.

Related keywords and their meanings

NOTE Keywords are case-insensitive and arguments are case-sensitive. This is not a comprehensive list of keywords. This list simply calls out certain keywords that are relevant to how Trust Protection Foundation processes the sshd_config file.

Keyword Description

Keyword	Description
AuthorizedKeysCommand	Specifies a program to be used to look up the client's public keys. The program must be owned by root and not writable by group or others. If a key supplied by `AuthorizedKeysCommand` does not successfully authenticate and authorize the user, then public key authentication continues using the usual `AuthorizedKeysFile` files. By default, no `AuthorizedKeysCommand` is run. SSH Manager for Machines only supports the following value for `AuthorizedKeysCommand`: AuthorizedKeysCommand none If `AuthorizedKeysCommand` is defined as anything else in sshd_config, Trust Protection Foundation will log an error.
AuthorizedKeysFile	Specifies the file that contains the public keys that can be used for user authentication. NOTE If you specify a location with this keyword in the sshd_config file, these folders will always be scanned for keys, in addition to any directories specified as Scan Paths in the Work. To exclude scanning the sshd_config file, you need to add `/etc/ssh/sshd_config` file to the Exclude Paths of the Work assignment.
Match <user> \| <group>	Allows you to direct parameters at certain users or groups. Trust Protection Foundation does not support the Match keyword, and will ignore any AuthorizedKeysFile parameters in a Match block.

AuthorizedKeysCommand

Specifies a program to be used to look up the client's public keys. The program must be owned by root and not writable by group or others.

If a key supplied by AuthorizedKeysCommand does not successfully authenticate and authorize the user, then public key authentication continues using the usual AuthorizedKeysFile files.

By default, no AuthorizedKeysCommand is run.

SSH Manager for Machines only supports the following value for AuthorizedKeysCommand:

AuthorizedKeysCommand none

If AuthorizedKeysCommand is defined as anything else in sshd_config, Trust Protection Foundation will log an error.

AuthorizedKeysFile

Specifies the file that contains the public keys that can be used for user authentication.

NOTE If you specify a location with this keyword in the sshd_config file, these folders will always be scanned for keys, in addition to any directories specified as Scan Paths in the Work. To exclude scanning the sshd_config file, you need to add /etc/ssh/sshd_config file to the Exclude Paths of the Work assignment.

Match <user> | <group>

Allows you to direct parameters at certain users or groups. Trust Protection Foundation does not support the Match keyword, and will ignore any AuthorizedKeysFile parameters in a Match block.

Displaying the sshd_config file

When using an agent to discover SSH keys, Trust Protection Foundation doesn't have direct access to the sshd_config file, so you can't view the file in web-based admin console. However, if you are using agentless discovery, Trust Protection Foundation processes the sshd_config file as part of the discovery process, so it can display the contents of the file in SSH Manager for Machines. For more information, see Viewing the sshd_config file.