Your browser does not allow storing cookies. We recommend enabling them.

SSH Tectia

User Authentication with Public Keys

Public-key authentication is based on the use of digital signatures. Each user creates a pair of key files. One of these key files is the user's public key, and the other is the user's private key. The server knows the user's public key, and only the user has the private key.

The key files must be stored to a location where the user has the write rights, (and read rights), but that is not accessible to others. These user-specific rights are required for the file, the authorized_keys directory, and to the authorization file, if used.

When the user tries to authenticate, the client sends a signature to the server, and the server checks for matching public keys. If the key is protected with a passphrase, the server requests the user to enter the passphrase.

Remember that your private-key file is used to authenticate you. Keep your private-key file in a secure place and make sure that no one else has access to it. If anyone else can access your private-key file, they can attempt to log in to the remote host computer pretending to be you. Define a passphrase to protect your private key, whenever possible. On a machine shared by several users, make sure that the permission settings do not allow others to access your private key.


Do not store your private keys in a location accessible to other users.

Also note that if you are using the Windows roaming profiles functionality, your personal settings will be replicated with the roaming profile server. If you store your private keys in the default location (under the profile folder of your Windows user account) your private keys may be susceptible to a malicious user listening to the network traffic. Therefore the User Settings folder should not be a directory that is used in profile roaming.

To use public-key authentication with SSH Tectia ConnectSecure, do the following actions:

  1. Generate a key pair. You can generate your own key files with the help of a built-in Public-Key Authentication Wizard on Windows (see Creating Keys with the Public-Key Authentication Wizard (Windows)), or with ssh-keygen-g3 on Unix or Windows command line (see Creating Keys with ssh-keygen-g3).

    You can also import existing keys on the Keys and Certificates page of the SSH Tectia Configuration tool. See Managing Keys and Certificates.

  2. Upload your public key to the remote host computer. On Windows, you can do this automatically (see Uploading Public Keys Automatically). On Unix and Windows, you can also copy the public key manually (see Uploading Public Keys Manually).

In the following instructions, Server is the remote host running the Secure Shell server that you are trying to connect to. ServerUser is the username on Server that you are logging in as. Client is the host running the Secure Shell client (SSH Tectia ConnectSecure). ClientUser is the username on Client that should be allowed to log in to Server as ServerUser. See Figure 5.4.

User public-key authentication

Figure 5.4. User public-key authentication

The instructions assume that ClientUser is allowed to log in to Server as ServerUser using some other authentication method (usually password).


Highlights from the SSH.COM blog:

  • Cryptomining with the SSH protocol: what big enterprises need to know about it

    Cryptomining malware is primarily thought of as targeting desktops and laptops and is used to hijack system resources to mine cryptocurrency.
    Read more
  • SLAM the door shut on traditional privileged access management

    Did you know that something as trivial-sounding as granting access for your developers or third parties to a product development environment can throw a gorilla-sized monkey wrench into your operations and productivity?
    Read more
  • We broke the IT security perimeter

    Everyone understands the concept of a security perimeter. You only gain access if you are identified and authorized to do so.
    Read more