SSH - Client Keys - Holding Tank
- Last Updated: November 5, 2025
- 5 minute read
- MOVEit Transfer
- Version 2026
- Version 2025
- Documentation
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.
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.
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)
Step 2: Administrator Accept or Rejects the Pending SSH Key
- Sign on as Admin to MOVEit Transfer.
- Use the link provided in the New Client in Holding Tank notification.
- Sign on as an Admin to MOVEit Transfer.
- 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
-
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.