Editing Access to an SSH Server

Using the Edit Access function you create mappings between Keyfactor Command user accounts associated with SSHClosed 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. keys and Linux logons in order to publish the SSH public keys to the Linux servers (see SSH). You can also remove the mappings from here, which causes the SSH public keys to be removed from the Linux servers.

Before adding a logon to user mapping, be sure that you have switched the server to which you will add your mapping (or its server group) to inventory and publish policy mode (see Server Manager) so that the key for the user will be published to the server. If the server is in inventory only mode and you add a mapping for it in Keyfactor Command, the mapping will appear in Keyfactor Command only and the key for the user will not be published out to the server.

To edit the access for a server, create a mapping between a Linux logon and a Keyfactor Command user, and publish the user's key to the SSH server:

  1. In the Management Portal, browse to SSH > Server Manager.
  2. On the Server Manager page, select the Servers tab.
  3. In the Servers grid, locate the server that you wish to publish an SSH key to by mapping a Keyfactor Command user to a Linux logon on that server.
  4. Right-click the server and choose Edit Access from the right-click menu or highlight the row in the servers grid and click Edit Access at the top of the grid.

    Figure 327: Edit Access for an SSH Server

  5. On the Access Management page, select an existing Logon on the left side of the page. If you wish to add a new logon, enter the new logon name in the Logon field at the top of the left side of the page and click Add Logon. The new logon appears at the bottom of the Logon list. Click the Logon list title to sort the list, if desired. Select the new logon. Only one logon may be selected.

    Tip:   If you have enabled SSSD support for your Keyfactor Bash OrchestratorClosed The Bash Orchestrator, one of Keyfactor's suite of orchestrators, is used to discover and manage SSH keys across an enterprise. and are adding a domain user, specify the user in username@domain format. For example bbrown@keyexample.com (or, depending on SSSD configuration, such as the case-sensitivity setting; BBROWN@keyexample.com). Note that the logon may be modified by the SSSD configuration file in ways in which Keyfactor Command cannot know about. Refer to SSH-SSSD Case Sensitivity Flag for guidance on what to enter based on how the SSSD case sensitivity flag is configured.
  6. In the Users dropdown at the top of the right side of the page, select a user or service account to associate the logon with. Only Keyfactor users that have keys stored in Keyfactor Command, that have been designated as server group owners, or AD users or groups that have been previously entered for association with a logon will appear in the dropdown. If desired, you may enter an Active Directory user or group name in this field. Using an Active Directory group to create Linux logon to Keyfactor user mappings will cause the keys stored in Keyfactor Command for any Active Directory users that are members of this group to be mapped to the selected Linux logon and published to the server on which the Linux logon exists. Any Active Directory users that are members of this group but who do not have keys stored in Keyfactor Command will not be mapped to the selected Linux logon. Click Add User.

    Tip:  For keys created through the My SSH Key portal (see My SSH Key), a Keyfactor user is an Active Directory user account. For keys created through the Service Account Keys page (see Service Account Keys), a Keyfactor user is a user-generated service account name of the form servicename@hostnameClosed 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)..
  7. Repeat step 6 for any other user or service accounts that you wish to map to this logon on this server.
  8. Click Save.

To remove a mapping of a Linux logon to a Keyfactor Command user for a server, removing the public keyClosed 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. from the Linux logon's authorized_keys file:

  1. In the Management Portal, browse to SSH > Server Manager.
  2. On the Server Manager page, select the Servers tab.
  3. In the Servers grid, locate the server that you wish to remove an SSH key from by unmapping a Keyfactor Command user from a Linux logon on that server.
  4. Right-click the server and choose Edit Access from the right-click menu or highlight the row in the servers grid and click Edit Access at the top of the grid.

    Figure 328: Edit Access for an SSH Server

  5. On the Access Management page, select a Logon on the left side of the page. Only one logon may be selected.
  6. In the Users section on the right side of the page, select a user or service account to unmap from the logon. Click Remove Access under Users. The Linux logon to Keyfactor user mapping for the selected user will be removed and the user's SSH key will be removed from the authorized_keys files of the Linux logon on the selected server.

    Tip:  Clicking Remove All Access for Logon on the Logons side of the page removes all Linux logon to Keyfactor user mappings for the selected logon on the selected server with one click without the need to select the users on the Users side of the page.

    This option does not delete the logon from any servers (see Editing or Deleting a Logon).

  7. Repeat step 6 for any other user or service accounts that you wish to unmap from this logon on this server.
  8. Click Save.
Tip:  The time it will take for changes to access mappings to appear on your Linux server will depend on the frequency of the server synchronization configured for the server group to which the server belongs (see Adding Server Groups).