Skip to main content
SSH (Secure Shell) is a cryptographic network protocol that enables secure remote logins from one computer to another. The SSH protocol employs a client-server architecture, whereby you can establish a connection through an SSH client connecting to an SSH server. The SSH client drives the connection setup process and uses public key cryptography to verify the SSH server identity. After the setup phase, the SSH protocol uses strong symmetric encryption and hashing algorithms to ensure the privacy and integrity of the data exchanged between the client and server.

​
SSH client authentication methods

You can use the methods in this section to authenticate an SSH client to the SSH server. The most common methods are password and public key authentication.

​
Password authentication

With password authentication, an SSH client authenticates to an SSH server by using the password of a user on the SSH server. For example, an SSH client might try to establish an SSH connection by using the following command:
Text
ssh username@server.com
The system then prompts the SSH client for the password of the remote user it’s attempting to connect with. If the password entered matches the password of the remote user on the SSH server, the remote login session is established.

​
Public key authentication

The public key authentication method is often preferred over password authentication because it is more secure and allows for increased automation. After you set up public key authentication, the SSH client no longer needs to enter a password every time it connects. Perform the following steps to set up public key authentication:
  1. Generate an SSH key pair (public key and private key) on the SSH client.
  2. Move the SSH client public key to the SSH server (for example, by using SCP or SFTP) and add it to the ~/.ssh/authorized_keys file.
Now, when the SSH client attempts to connect by using the ssh username@server.com command, the system should not prompt it for the remote user’s password. Instead, the following process occurs in the background during the connection:
  1. The SSH client sends the following command to connect to the SSH server: ssh username@server.com
  2. The SSH server checks its ~/.ssh/authorized_keys file and finds a public key for the user that the SSH client is attempting to connect with.
  3. The SSH server then asks the SSH client to sign some arbitrary data using its SSH client private key to prove that the SSH client has the private key corresponding to the public key.
  4. The SSH client then sends data signed with the private key back to the SSH server, which then attempts to decrypt the data by using the public key it has for the user the SSH client is connecting with.
  5. If the decryption succeeds, the SSH server trusts the SSH client, establishing authentication.

​
How does CryptoHub fit into the process?

By default, when you use the ssh-keygen command on an SSH client machine to create an SSH key pair, the process stores the private key in a plaintext file in the ~/.ssh directory. This poses a security risk because anyone accessing that machine can view the private key and use it to authenticate to remote machines over SSH. Incorporating the CryptoHub into this process enables you to store the SSH client private key within the confines of a FIPS 140-2 Level 3-validated HSM. SSH integrates with CryptoHub through the PKCS #11 library. With CryptoHub incorporated in this process, the SSH client can send the following command to connect to the SSH server, where FXPKCS11_MODULE_LOCATION is the location of the FXPKCS11 library file (libfxpkcs11.so on Linux and fxpkcs11.dll on Windows):
Text
ssh -I [FXPKCS11_MODULE_LOCATION] client@server.com
Now, when the SSH client needs to sign data by using its private key (steps 3-4 in the previous section), its configuration points to the PKCS #11 library, which then automatically authenticates to the CryptoHub with an identity and password set in the FXPKCS11 configuration file. CryptoHub then signs some arbitrary data by using the private key corresponding to that identity and sends the signed data back to the SSH client, which forwards it to the SSH server.