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 Protect for devices that use agentless discovery.

Administrators can get information about the contents of sshd_config (on agentless devices) without the need to access the box directly.

Trust Protection Platform looks at sshd_config and determines the paths to look for the authorized keys. Based on those paths, it then looks for the actual keys authorized to access the device.

Format of the ssh_config file

The ssh_config file follows the OpenSSH standard. This file includes a directive that tells servers where the authorized keys file(s) are stored.

Visit https://www.ssh.com/ssh/authorized_keys/openssh.

Location of the AuthorizedKeysFile

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 contain one of several variables, as described in the table below.

Variable	Description	Example	Exceptions
%%	Replaced by a literal %
%h	Replaced by the home directory of the user being authenticated	%h/.ssh SSH server would look for authorized keys for the logged-in user jane in: /home/jane/.ssh	Does not support file names. Only supports one location for %h, not separate home directory locations for each user. Only supports the default home directory for the OS. (For example, /home/ for Linux.)
%u	Replaced by the login name of the user	/var/ssh/%u/ak SSH server would look for authorized keys for the logged-in user jane in: /var/ssh/jane/ak

Variable

Description

Example

Exceptions

Replaced by a literal %

Replaced by the home directory of the user being authenticated

%h/.ssh

SSH server would look for authorized keys for the logged-in user jane in:

/home/jane/.ssh

Does not support file names.

Only supports one location for %h, not separate home directory locations for each user.

Only supports the default home directory for the OS. (For example, /home/ for Linux.)

Replaced by the login name of the user

/var/ssh/%u/ak

SSH server would look for authorized keys for the logged-in user jane in:

/var/ssh/jane/ak

Trust Protection Platform does not support the following:

Cases in which no variable is used. For example, /var/ssh/jane/ak is not a supported value.
Multiple variables in the same parameter. For example, %h/%u/.ssh is not a supported value.

After expansion, AuthorizedKeysFile is taken to be an absolute path or one relative to the user's home directory.

If the AuthorizedKeysFile option is not present in the file, or if it is blank, Trust Protection Platform uses the default key file locations, which are:

.ssh/authorized_keys
.ssh/authorized_keys2

If Trust Protection Platform finds an unsupported value in the AuthorizedKeysFile option, or if the option is present, but cannot be understood by Trust Protection Platform, it will log an error.

If the AuthorizedKeysFile option contains multiple locations, separated by spaces, Trust Protection Platform will use all specified locations.

If more than one AuthorizedKeysFile option is in the sshd_config file, Trust Protection Platform will only use the first instance of the parameter, and will ignore subsequent AuthorizedKeysFile parameters.

During discovery, if SSH Protect finds files that look like authorized keys, but are not in a specified authorized keys directory, they are treated as "idle public keys."

What kinds of public keys does SSH Protect support?

SSH Protect recognizes the following types of public keys:

Authorized keys. Public keys stored in a recognized authorized keys file that permit a client with the matching private key access to this device.
Known host keys. Public keys stored in the known-hosts file that permit this client to connect with a server with the matching private key.
Idle Public keys. Public keys found during discovery that were not in a recognized authorized keys file, or in a known-hosts file. These public keys are likely able to be removed from the device.

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 Platform will only look for the sshd_config file in the following location:

/etc/ssh/sshd_config

If Trust Protection Platform does not find the sshd_config file in that location, it will log an error in the Trust Protection Platform log and will use the default key file locations.

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 Platform 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 Protect only supports the following value for `AuthorizedKeysCommand`: AuthorizedKeysCommand none If `AuthorizedKeysCommand` is defined as anything else in sshd_config, Trust Protection Platform 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 Platform 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 Protect only supports the following value for AuthorizedKeysCommand:

AuthorizedKeysCommand none

If AuthorizedKeysCommand is defined as anything else in sshd_config, Trust Protection Platform 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 Platform 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 Platform doesn't have direct access to the sshd_config file, so you can't view the file in Aperture. However, if you are using agentless discovery, Trust Protection Platform processes the sshd_config file as part of the discovery process, so it can display the contents of the file in SSH Protect. For more information, see Viewing the sshd_config file.