SSH Server Key Verification
Understanding SSH Server Key Verification
When an SSH server is accessed, it presents a public key that uniquely identifies it. This key allows the client to verify the server’s identity and prevent man-in-the-middle attacks. The SSH protocol relies on the client maintaining a fingerprint of the server’s public key, which is then compared on each connection attempt. A match confirms that the client is communicating with the expected server.
Enabling SSH Key Verification in Assets
By default, the 12Port Server does not enforce public key verification for SSH connections. However, this verification can be optionally enabled for both job execution and peer tunnel connections.
Storing the Server's Public Key
To support SSH key validation, you must first configure the associated SSH asset to store the server’s public key:
- Edit the SSH-related asset type from the Management > Asset Types page.
- Click Add Field and add a new String field named
Public Key
.- This field will be used to store the trusted server key fingerprint.
- Initially, it will be empty and used to display the option to Verify SSH Server Trust.
Public Key Field Interaction
Clicking the Verify SSH Server Trust button will launch a dialog displaying the SSH public key retrieved from the target server.
Establishing Trust with the Server
The system will show the detected public key for manual verification. If the key is correct and matches expectations, click Establish Trust to save the fingerprint and complete the trust establishment process.
Once this is done, any SSH-based tunnels will use the stored public key to validate the remote server during connection establishment.
Enforcing Server Validation for Job Execution
To apply server key verification during script execution (e.g., for job automation), take the following steps:
- Add a Checkbox field named
Verify Server Key
to the SSH asset type. - Enable this option in the asset configuration.
When enabled, this setting instructs the system to validate the server’s identity using the stored key before executing jobs over SSH.