Editing Access to an SSH Server Group

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 all the Linux servers that belong to the selected server group (see SSH). You can also remove the mappings from here, which causes the SSH public keys to be removed from the Linux servers belonging to the selected server group.

Before adding a logon to user mapping, be sure that you have switched either the server group or all servers in the group to which you will add your mapping to inventory and publish policy mode (see Server Manager) so that the key for the user will be published to the servers in the group. If the servers in the server group are 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 servers in the server group. If only some servers in the server group are in inventory and publish policy mode, the key for the user will only be published to those servers.

Tip:  The time it will take for changes to access mappings to appear on your Linux servers will depend on the frequency of the server synchronization configured for the server group (see Adding Server Groups).

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

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

    Figure 313: Edit Access for an SSH Server Group

  5. On the Access Management page, select an existing Logon on the left side of the page. Logons only appear here if they exist with the same spelling on all servers in the server group. 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 servers 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 the servers in this server group.
  8. Click Save.

To remove a mapping of a Linux logon to a Keyfactor Command user for all the servers in a server group, remove 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 files:

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

    Figure 314: 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 logons on all the servers in the server group.
    Tip:  Clicking Remove Shared Access for Logon on the Logons side of the page removes all Linux logon to Keyfactor user mappings for the selected logon with one click without the need to select the users on the Users side of the page.

    If a logon has user mappings on some servers and not others in the group (see the example, below), these will not appear in the Server Group Edit dialog, and none of these user mappings will be removed. The Remove Shared Access for Logon option only removes user mappings that are visible in the Server Group Access dialog.

    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 the servers in this server group.
  8. Click Save.
Example:  Server Group One contains three Linux servers—A, B and C. Linux logons for Anne, Betty and Dave exist on all three servers. A Linux logon for Chuck exists on servers A and B but not C. In Keyfactor Command:
  • Anne has acquired an SSH key using My SSH Key (see My SSH Key) and an administrator has mapped it to her Linux logon for all three servers in Server Group One.
  • Betty has acquired an SSH key using My SSH Key and an administrator has mapped it to her Linux logon account for servers A and B but not server C.
  • Chuck has acquired an SSH key using My SSH Key and an administrator has mapped it to his Linux logon account for servers A and B. No Linux account exists for Chuck on server C and no user mapping has been done for Chuck for this server.
  • Dave has acquired an SSH key using My SSH Key but it has not yet been mapped to his Linux logon account for any servers.

You can see these Linux logon to Keyfactor user mappings in Figure 315: Linux Logon to Keyfactor User Mappings for Anne, Betty, Chuck and Dave.

Figure 315: Linux Logon to Keyfactor User Mappings for Anne, Betty, Chuck and Dave

As a result of this logon setup and mapping configuration, when you open the Server Group Access dialog for Server Group One (see Figure 316: Server Group Access Editing Example), in the Logon column you will see anne, betty and dave but not chuck.

  • Chuck is missing because he does not have a Linux logon account on server C.
  • As you click on each of the users anne, betty and dave in the Logon column, on the right in the Users column, you will see that:
    • Anne's mapped user appears, but a mapped user does not appear for either Betty or Dave.
    • In Betty's case, this is because her Keyfactor user to Linux logon mapping does not exist for server C. Mapped users only appear if they are consistent across all Linux logons for a user.
    • In Dave's case, this is because he does not have a Keyfactor user to Linux logon mapping for any of the servers.
  • Other shared Linux logons exist on the servers—such as root—that are not referenced in this example but are shown in Figure 316: Server Group Access Editing Example.
    • Tip:  Logons only appear in the Linux logon column if they exist with the same spelling on all servers in the server group—dave does not equal david and will not be recognized as a Linux logon match.

Figure 316: Server Group Access Editing Example

The administrator decides to do the following:

  • On the Server Groups tab, she selects Server Group One and clicks Edit Access at the top of the grid.
  • In the Server Group Access for Server Group One, she adds a Linux logon for chuck on the left and clicks Save without adding any user mappings on the right.
  • Since Chuck already had Linux logon accounts on servers A and B, no changes are made on those servers. A Linux logon account is added on server C for Chuck.
  • When the administrator opens the Server Group Access for Server Group One again, she sees Chuck's Linux logon on the left. When she clicks on chuck, no Users are shown on the right because Chuck only has Linux logon to Keyfactor user mappings for servers A and B, not for server C.

    Figure 317: Concept: Add Linux Logon for Chuck on Server C

  • In the Server Group Access for Server Group One, she selects chuck on the left and creates a mapping to Chuck's SSH key acquired through My SSH Key. This adds the key to the authorized_keys file for Chuck on any servers in the server group that lack the key—in this case, server C. This then completes the mappings for Linux logon the Keyfactor user for Chuck for the servers in this server group. Chuck's user will then appear in the Server Group Access dialog when Chuck's Logon is selected.

    Figure 318: Server Group Access: Add Linux Logon for Chuck on Server C

  • In the Server Group Access for Server Group One, she selects betty on the left and creates a mapping to Betty's Active Directory account, which is associated with the SSH key acquired through My SSH Key, and to a service account key for Betty—svc_grnchk@appsrvr12 and clicks Save. Since Betty already had Linux logon to Keyfactor user mappings for servers A and B and her SSH key was already on these servers, no changes are made to these servers. Her key acquired through My SSH Key is published out to server C and added to her authorized_keys file on that server. Betty had no previous mappings for the SSH service key svc_grnchk@appsrvr12, so this key is published out to all three servers in the server group and added to her authorized_keys files on those servers.

    Figure 319: Add Logon to User Mapping for Betty

  • At a later date, the administrator decides to remove Betty’s access to the service account key. In the Server Group Access for Server Group One, she selects betty on the left and selects the service account key svc_grnchk@appsrvr12 on the right. She clicks Remove Access and then Save. The SSH key for the svc_grnchk@appsrvr12 service is removed from Betty's authorized_keys file on servers A, B and C. When she opens the Server Group Access dialog again and selects Betty, she sees Betty's Active Directory account, associated with the SSH key acquired through My SSH Key, but not the svc_grnchk@appsrvr12 service account.

    Figure 320: Remove Logon to User Mapping for Betty

  • She decides to add Dave’s key to the servers. On the Logons tab, she selects one of Dave's Linux logons on one of the servers in Server Group One and clicks Edit at the top of the grid. In the Edit Logon dialog, she changes to the Access Management tab, selects Dave's Active Directory account in the Users dropdown, and clicks Add User and Save. She repeats these steps for all the servers in Server Group One (servers A, B and C). Dave's SSH key acquired through My SSH Key is published out to all three servers in Server Group One and added to his authorized_keys files on those servers.

    Figure 321: Add Individual Logon to User Mappings for Dave

  • On the Server Groups tab, she selects Server Group One and clicks Edit Access at the top of the grid. In the Server Group Access for Server Group One, she selects Dave's Linux logon and sees that Dave's Active Directory account appears in the Users section on the right when it did not previously. This is because she created Linux logon to Keyfactor user mappings for Dave individually on the Logons tab for all the servers in Server Group One. If she had only done this for some of the servers in Server Group One, Dave's Active Directory user would not appear on the Server Group Access dialog.

    Figure 322: View Server Group Logon to User Mappings for Dave