VanDyke Software



Using Public-Key Authentication in Secure Shell Applications

The tip below provides a basic overview of public-key authentication, explains how to generate and upload keys to the Secure Shell server, and shows how to configure SecureCRT and SecureFX clients.

Overview of public-key authentication for Secure Shell

Public-key authentication is a proven, well-established method for authenticating computing devices which is more secure than password authentication. Public-key authentication employs a linked pair of computer-generated keys — one public and one private — and a procedure that proves the user's identity without exposing the secret key to theft or hijacking.

Before using public-key authentication, the public/private key pair files must be created, with a copy of the public-key file being uploaded to a specific location on the server. The public and private keys are generated with a key generation utility. While the private and public keys within a key pair are related, a private key cannot be derived by someone who only possesses the corresponding public key.

Public-key authentication is only successful when the client proves that it possesses the "secret" private key linked to the public-key file that the server is configured to use. Typically the private-key file on the client's machine is protected by a "passphrase", so even if the private-key file is stolen, an attacker must still know the passphrase in order to use it. In contrast with the "password" authentication method where the password is transmitted between the client and the server during the authentication process, the private key contents are not transmitted between the client and the server. Since the private key is never transmitted over the connection, the public-key authentication method is considered to be more secure than the password authentication method. Each key is usually between 1024 and 2048 bits in length. Starting with SecureCRT and SecureFX 7.3 and newer, keys larger than 2048 are available if needed. The following is an example of a key generated by SecureCRT.

  ---- END SSH2 PUBLIC KEY ---- 

Successful public-key authentication requires: (1) generating a key pair, (2) uploading the public key to the Secure Shell server, and (3) configuring the client to use the public-key authentication method. SecureCRT and SecureFX provide utilities to generate keys and automatically place a copy of the public key on a VShell® server. Public-key authentication between a VanDyke Software client application and a non-VShell server such as OpenSSH requires generation of a public/private key pair and placing the public-key file on the server in the right location and in a format supported by the Secure Shell server.

Generating VanDyke Software keys, configuring client applications

VanDyke Software applications generate public/private keys using a simple wizard or a command-line utility. In the SecureCRT or SecureFX Tools menu, the Create Public Key… menu item launches the Key Generation wizard. The Public-Key Assistant toolbar button (also found in the Tools menu) may also be used to generate keys.

Key Generation Wizard Step 1

You first choose the type of key (RSA, Ed25519, ECDSA, or DSA) and the passphrase that is used to protect access to your private key. If using an RSA key type and SecureCRT or SecureFX 7.3 or newer, you can then select a key length between 512 and 16,384 bits (SecureCRT and SecureFX versions 7.2 and earlier are limited to key lengths between 512 and 2048 bits). In many organizations, users are given guidelines for these settings. The time required to generate a key increases with the key length, and may be several minutes depending on processor speed.

Key Generation Wizard Key Type Selection





You will have the choice of storing your key in VanDyke Software format (the public key is stored in a file that matches the IETF standard format) or in the OpenSSH format. If you are connecting to an OpenSSH server, you may want to use the OpenSSH format to simplify the process involved with setting up the remote server with your public-key file. If you are connecting to a VShell server, you can use either format since VShell accepts them both.

Public- and private-key files are placed in a local folder on the machine where the client application resides, usually with the filename "Identity".

The public key can be uploaded to a VShell server at the end of the Key Generation wizard process, or at any time later through the Session Options dialog. Use the following steps to upload an existing public-key file:

1. In the SSH2 category of Session Options, select the PublicKey option in the Authentication section, then press the Properties button.

2. In the Properties dialog, find the Use identity or certificate file section, and press the file browser button (…).

3. Navigate to the key file you want to use in the Select Identity Filename dialog.

4. Press the Upload button to place the public key on the Secure Shell server.* Note that you can also create keys from this dialog with the Create Identity File... button. This is also where you can change the passphrase for your key.

*Note that the upload instructions apply only to servers like VanDyke Software's VShell that implement the Secure Shell Public Key Subsystem (RFC 4819). Although there may be server implementations that support the public-key subsystem, those connecting to servers that aren't VShell will typically need to use manual methods to place their public-key files on the server to meet the server's requirements.

Default key file locations

If you need to configure sessions in the future and can't find your key files, the following table illustrates the default locations used by the public-key wizards on each of the indicated platforms.

Platform Key File Location Example
Windows Documents folder C:\Users\JoeRocket\Documents
macOS .ssh folder in the user's home directory /Users/JoeRocket/.ssh
Linux user home directory /home/JoeRocket

VanDyke Software uses cookies to give you the best online experience. Before continuing to use this site, please confirm that you agree to our use of cookies. Please see our Cookie Usage for details.