Typical Scenario to Add New Client SSH Key to Holding Tank

MOVEit Transfer SSH or SFTP client users can attempt to connect with a new and unrecognized key. If this happens, the administrator will be notified, and the key will be copied to the holding tank for an administrator to eventually approve or reject the key (using admin controls provided from the MOVEit Transfer user's User Profile view).

When using a key as part of authentication, the holding tank makes it easy for administrators to "click-accept" specific keys for specific users without having to manually copy or type keys into a user profile.

Important: The MOVEit user needs to have a generated and installed SSH client key on their local machine or device before they can use this feature.

For detailed information about configuring the SSH Keys policy, please also see the Interface Policy documentation page.

Basic Workflow

The SSH Client Key Holding Tank holds any public key presented by a user attempting to connect if the key cannot be identified by the MOVEit Transfer SSH Server pending key approval by the administrator. The following points outline the workflow:

  • MOVEit Transfer populates the client key holding tank automatically.

    This occurs when a valid username is presented along with a new (unrecognized) key (pending approval) AND the sign-on fails (for example, the sign-on fails because a key was required as part of the site's MOVEit SSH policy).

  • Unrecognized client SSH keys are placed in the pending state.

  • MOVEit Transfer sends a New Key in Holding Tank notification.

    MOVEit Transfer notifies the administrator (email, for example) when a New Key in Holding Tank action occurs.

  • Org Admin checks that key is valid and approves or rejects it.

    Approving a key () promotes it to the Current SSH Key list. Always verify the time sent, fingerprint, and user.

Note: MOVEit Transfer uses a username and the full public SSH key to identify a valid user session. Using MD5 fingerprints to validate sessions is deprecated in favor of full public SSH key.

Step 1: Client Attempts to Connect with SFTP or SSH

This section outlines how you can leverage the "click-accept" ease if the holding tank feature.

First, with your client user's SSH public key in the appropriate default folder on their client machine, have the user attempt an SFTP or SSH connection to MOVEit Transfer. Initially, this connection should fail with the side effect of their public key copied to the MOVEit Transfer Holding Tank.

For example, each of the following (a Linux BASH and Powershell session example) attempts to connect with the user's current client key and fails. (It fails because the public key presented needs to be approved by the administrator.)

Example 1: SSH Session (Linux BASH command-line client shown)

$ ssh 10.65.18.222 -l audituser01
            audituser01@10.65.18.222's password:
            PTY allocation request failed on channel 0
            shell request failed on channel 0

(Request failed but client's public key copied to MOVEit and in Holding Tank, pending)

Example 2: SFTP Session (Windows Powershell client shown)

PS C:\Users\jsmith> sftp audituser01@10.65.18.222
            audituser01@10.65.18.222's password:
            audituser01@10.65.18.222: Permission denied (publickey).
            PS C:\Users\jsmith>

(Request failed but client's public key copied to MOVEit and in Holding Tank, pending)

Note: Pending Client Key approvals trigger an email notification. The email notification occurs when MOVEit Transfer detects an unrecognized client key and adds it to the client key holding tank.

Step 2: Administrator Accept or Rejects the Pending SSH Key

For Step 2 in the workflow, as administrator you can either:
  • Sign on as Admin to MOVEit Transfer.
  • Use the link provided in the New Client in Holding Tank notification.
  1. Sign on as an Admin to MOVEit Transfer.
  2. Go to either the:
    • User Profile of the user that just tried to authenticate if you know it, and click the SSH Policy link, or...
    • The organization holding tank under SETTINGS > Security > Interface Policy | SSH.

    The SSH Policy page displays.

    Figure 1. SSH Policy View
  3. Review the current public key and then click the accept button () to apply it to the user's current SSH keys.

    Note: An administrator should accept a key from the holding tank only if there is good reason to trust that the connection attempt that resulted in the holding tank entry actually came from the authorized user.
    Figure 2. Keys Awaiting Review in User's Holding Tank

    If the public client key has the expected length and format, MOVEit Transfer sends a New Key in Holding Tank notification to the administrator. You can now click on the accept key button to apply the key for future successful sign-on. Current SSH Keys section. A single user can be associated with multiple SSH keys. For example, this might be useful if a user uses the same account name from multiple machines.

    Finally, to ensure the key will be solicited from the SSH client and/or that the key will be a required credential, see the Edit SSH Policy section and check the boxes appropriately.

    If you plan on using OpenSSH in batch mode, you should use the following settings (require_key = yes, require_pass_with_key = no). If you want to enforce "two-factor" authentication, enable all of the following settings (require_key = yes, require_pass_with_key = yes).

Importing Keys from the Organization-Wide Holding Tank

A complete list of all unassigned keys for all users in the organization may be viewed in the organization-wide holding tank. The organization-wide holding tank is accessible from the Settings page by following the Security | Interface Policy | SSH link. To assign specific keys, click the View Tank Keys link to view the complete list.

Keys are listed by username. Select the appropriate key and click the accept button ().

Cleaning Unassigned Keys Out of the Holding Tank

Unassigned keys will automatically be removed from the holding tank after a certain number of days. The exact number of days is a configurable option under the organization-wide SSH policy. (The same value applies to unassigned SSL client certs and untrusted CA certs in the holding tank.)

Unassigned keys may also be manually cleaned out an individual user's holding tank or the organization-wide holding tank using any of the provided delete all links.