SSH

Keyfactor SSH The SSH (secure shell) protocol provides for secure connections between computers. It provides several options for authentication, including public key, and protects the communications with strong encryption. Management is designed to allow organizations to inventory and manage secure shell (SSH) keys across the enterprise. The solution consists of two elements; the SSH functionality on the Keyfactor Command Management Portal and the Keyfactor Bash Orchestrator The Bash Orchestrator, one of Keyfactor's suite of orchestrators, is used to discover and manage SSH keys across an enterprise..

The Keyfactor Bash Orchestrator Keyfactor orchestrators perform a variety of functions, including managing certificate stores and SSH key stores. runs on Linux servers and can be operated in two possible modes:

• The orchestrator is used in inventory only mode to perform discovery of SSH public keys and associated Linux user accounts across multiple configured targets.

  

  Figure 291: SSH Key Discovery Flow

• When operated in inventory and publish policy mode, the orchestrator can be used to add SSH public keys and Linux user accounts on targets and remove rogue keys that appear without authorization.

  

  Figure 292: SSH User Key Management Flow

As you work with SSH keys in Keyfactor Command, you will need to understand the difference between users, service accounts, and logons:

• A user is an account in Keyfactor Command—based on an Active Directory user account—which has been granted the Keyfactor Command SSH User role permission (see SSH Permissions).

  A user can use the My SSH Key tool (see My SSH Key) to generate an SSH key pair In asymmetric cryptography, public keys are used together in a key pair with a private key. The private key is retained by the key's creator while the public key is widely distributed to any user or target needing to interact with the holder of the private key. for himself or herself. This stores the user's SSH public and private key Private keys are used in cryptography (symmetric and asymmetric) to encrypt or sign content. In asymmetric cryptography, they are used together in a key pair with a public key. The private or secret key is retained by the key's creator, making it highly secure. in the Keyfactor Command database. An administrator can then use one of the options in the SSH section of the Management Portal (see Editing Access to an SSH Server, Editing Access to an SSH Server Group, or Adding Logons) to map the user record and its associated public key In asymmetric cryptography, public keys are used together in a key pair with a private key. The private key is retained by the key's creator while the public key is widely distributed to any user or target needing to interact with the holder of the private key. to one or more logons, creating new logons if needed. For servers operating in inventory and publish policy mode, this will cause the user's public key to be published to the authorized_keys file(s) for each mapped logon on the associated SSH server(s) during the next synchronization job. The user downloads the private key of the key pair to his or her machine in the My SSH Key tool and retains it there to allow for SSH connections to the target servers the administrator distributes the matching public key to.

  Note:  If an administrator maps a user's public key to a logon for a server that is in inventory only mode, nothing will happen. The key will not be published to the server.
  Note:  OpenSSH maintains a file for each user that contains the public keys authorized to connect via SSH. By default, this file is named authorized_keys. In this document, we refer to this file as authorized_keys, however in your environment, this file may have a different name. The file name used in a given environment is defined in the AuthorizedKeysFile setting in the OpenSSH sshd_config file.

• A service account is a string representing a service for which an SSH key has been requested through the Service Account Keys page (see Service Account Keys). It is made up of the Username and Client Hostname entered during service account key creation in the form servicename@hostname The unique identifier that serves as name of a computer. It is sometimes presented as a fully qualified domain name (e.g. servername.keyexample.com) and sometimes just as a short name (e.g. servername). (e.g. myservice@appsrvr12).
  Tip:  The client hostname that makes up part of the service account name is not necessarily an actual server hostname. It is a user-defined reference that can contain any string.

  An administrator can use the Service Account Keys page (see Service Account Keys) to generate an SSH key pair for an application—referenced by a service account name—that makes use of SSH for communication, storing the application’s SSH public and private key in the Keyfactor Command database. The administrator needs to store the private key securely on the Linux server where the service account for the application can access it and follow the same procedure as for users to distribute the public key to the appropriate SSH server(s) operating in inventory and publish policy mode.

  Note:  If an administrator maps a service account's public key to a logon for a server that is in inventory only mode, nothing will happen. The key will not be published to the server.
• A logon is a Linux user account. In most cases for the purposes of SSH management, these are Linux user accounts that have or are intended to have SSH public keys associated with them on managed SSH servers, stored in an authorized_keys files. However, Linux logons without keys (and which should likely never have keys like "root" or OS-specific accounts like "halt") also appear in Keyfactor CommandSSH management.

Typically, you would initially configure your servers in inventory only mode and scan the servers for any existing authorized_keys files containing SSH public keys. This is the discovery phase. Once the discovery phase is complete for a server or server group, you would then switch it to inventory and publish policy mode.

When a server is in inventory and publish policy mode, any new keys that appear in its authorized_keys files in a manner other than by distribution from Keyfactor Command are automatically deleted. This allows administrators to closely control who has access to the servers via SSH. Any keys and authorized_keys files that were in place before the switch to managed mode are synchronized to Keyfactor Command (see Unmanaged SSH Keys) but not removed from the Linux server. The administrator can choose to remove them through Keyfactor CommandSSH management once the switch to inventory and publish policy mode is made, if desired. Any keys placed on the Linux server via Keyfactor Command once the servers are in inventory and publish policy mode are considered managed keys and do not appear on the Unmanaged Keys page.

As SSH servers are scanned for SSH keys during the initial discovery phase, the Linux user accounts associated with these keys are synchronized to Keyfactor Command. These user accounts—logons—can be viewed on the Logons tab under Server Manager. Once each server is switched to inventory and publish policy mode, these logons can be managed and additional logons can be added to the Linux servers via Keyfactor CommandSSH management.

For more information about the orchestrator, see Bash Orchestrator in the Keyfactor Orchestrators Installation and Configuration Guide.

The options available in the SSH section of the Management Portal are: