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 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.

How the system handles sshd_config access during discovery

During an agentless scan, the discovery service connects to the target server and reads the SSH configuration file (typically /etc/ssh/sshd_config).

The system handles the file according to the result of the read attempt:

  • The file is read successfully: The system updates the database with the current server configuration and discovers keys using the defined paths.

  • The file does not exist (No such file): The system recognizes that the configuration file was removed and updates the database accordingly.

  • The file cannot be read due to permission errors (Permission denied): If the discovery account cannot read the file or elevation fails, the system keeps the existing configuration in the database. It does not delete saved keys or remove the host configuration.

NOTE  If the discovery account cannot read sshd_config due to permission errors, existing configuration data is preserved in the database and an error is logged. This ensures your key inventory remains intact while you resolve host permissions.

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 support?

SSH Manager 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.

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.

Discovery logic: Agent vs. Agentless

Agentless discovery and Agent-based discovery use different methods to find SSH keys. It is important to choose the correct method so that the system assigns keys to the correct users.

Agentless discovery

Agentless discovery is the best choice for complex environments. It uses system-level data to find the "source of truth" on the host.

  • Uses system commands: The platform runs commands like getent to find a list of all users and their official home directories.

  • Reads configuration files: It reads the /etc/ssh/sshd_config file. It finds the exact location of the AuthorizedKeysFile, even if you have changed it from the default.

  • Resolves variables: It can process variables like %h (home directory) and %u (username). This ensures it finds keys even if a user has a non-standard home directory (for example, a user named bob who uses /home/maintenance/).

Agent-based discovery

The Server Agent is best for simple environments with standard settings. It uses a basic method to identify users.

  • Uses folder names: The Agent looks at the name of the folder to identify the user. For example, it assumes that a folder named /home/bob/ belongs to a user named bob.

  • Uses standard paths: The Agent does not read the sshd_config file. It only looks for keys in standard locations. It cannot find keys if you have moved them to a custom path.

  • Risk of errors: If a user's folder name is different from their username, the Agent might assign the keys to the wrong person or fail to find the keys.

Agent vs. Agentless comparison summary

Use the following table to compare how each discovery method handles non-standard configurations and how those methods affect the accuracy of your results.

Feature

Agentless

 Agent-based

Non-standard home folders

Supported. Uses system data to find the correct folder.

Not supported. Assumes the folder name is the username.

Custom key locations

Supported. Reads the path from sshd_config.

Limited. Only looks in standard locations.

Idle key detection

High accuracy. Corrects errors in non-standard paths.

Lower accuracy. May misidentify keys in custom folders as "Idle.".

 

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

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 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 more information, see Viewing the sshd_config file.