Skip to main content
This section covers SSH key offloading to the KMES Series 3 by using PKCS #11.

​
SSH overview

SSH (Secure Shell) is a cryptographic network protocol that enables secure remote login from one computer to another. The SSH protocol employs a client-server architecture, whereby a connection is established 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 several methods to authenticate the SSH client to the SSH server. The most commonly used are password and public key authentication.

​
Password authentication

With password authentication, an SSH client authenticates to an SSH server by using your password on the SSH server. For example, an SSH client tries to establish an SSH connection by using the following command:
Shell
ssh username@server.com
The SSH client is then prompted for your password, assuming you are the remote user with which it is attempting to connect. If the password entered matches your password on the SSH server, the remote login session is established.

​
Public key authentication

You might prefer public key authentication over password authentication because it is more secure and enables increased automation. After you set it up, the SSH client no longer needs to enter a password whenever it connects. Configure public key authentication with the following steps:
1
Generate an SSH key pair (public and private key) on the SSH client.
2
Move the SSH client public key to the SSH server (through 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 SSH server should not request your password as the remote user trying to connect. Instead, the following procedure shows what happens during the connection:
1
The SSH client sends the following command to connect to the SSH server:
Shell
ssh username@server.com
2
The SSH server checks its ~/.ssh/authorized_keys file and finds your public key 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 using the public key it has for you (the user the SSH client is connecting with).
If the decryption succeeds, the SSH server trusts the SSH client, establishing authentication.

​
How does the KMES Series 3 fit into the process?

By default, when you create an SSH key pair by using the ssh-keygen command on an SSH client machine, the private key is stored in a plaintext file in the ~/.ssh directory. This poses a security risk because anyone with access to that machine can view the private key and use it to authenticate to remote machines over SSH. Incorporating the KMES Series 3 into this process enables the system to store the SSH client private key within the confines of a FIPS 140-2 Level 3-validated hardware security module. SSH integrates with the KMES Series 3 through the PKCS #11 library. With the KMES incorporated into this process, the SSH client sends 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):
Shell
ssh -I [FXPKCS11_MODULE_LOCATION] client@server.com
Now, when the SSH client needs to sign data using its private key (steps 3-4 in the previous section), it is configured to point to the PKCS #11 library, which then automatically authenticates to the KMES with an identity and password set in the FXPKCS11 configuration file. The KMES 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.