SSH Key Offloading
SSH (Secure Shell) is a cryptographic network protocol that enables secure remote login from one computer to another.
The SSH protocol uses a client-server architecture, which means that the connection is established by 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's 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.
You can use several methods to authenticate the SSH client to the SSH server. The most commonly used are password and public key 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 would attempt to establish an SSH connection by using the following command:
The SSH client would then be prompted for your password, assuming you are the remote user it's attempting to connect with. If the password entered matches your password on the SSH server, the remote login session is established.
You might prefer public key authentication over password authentication because it is more secure and allows for 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:
Generate an SSH key pair (public and private key) on the SSH client.
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 [email protected] 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:
The SSH client sends the following command to connect to the SSH server:
The SSH server checks its ~/.ssh/authorized_keys file and finds your public key that the SSH client is attempting to connect with.
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.
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 will trust the SSH client, establishing authentication.
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 into this process allows 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 through the PKCS #11 library.
With the incorporated in this process, the SSH client would 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):
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 with an identity and password set in the FXPKCS11 configuration file. The then signs some arbitrary data 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.