How Secure Shell (SSH) Keys Work

How it works

SSH is a type of network protocol that creates a cryptographically secure connection between two parties. SSH authenticates the parties involved and allows them to exchange commands and output via multiple data manipulation techniques. It uses a symmetric cipher system like AES, Blowfish, 3DES, CAST128, and Arcfour to encrypt the entire connection, asymmetric encryption during the initial key exchange process to set up the symmetrical encryption and for key-based authentication, and hashing to generate hash-based message authorization codes (HMAC) that ensure a received message’s integrity is intact.

As Justin Elingwood of DigitalOcean explains, SSH encrypts data exchanged between two parties using a client-server model. The server listens to a designated port for connections, while the client is responsible for the Transmission Control Protocol (TCP) handshake with the server. That initial connection sets the stage for the server and client negotiating the encryption of the session based upon what protocols they support. To negotiate a session key, both parties use a version of the Diffie-Hellman algorithm to create a private key via an agreed upon seed value and encryption generator (such as AES) as well as a public key. Their private key, the other party’s public key, and the seed value form the basis for the shared secret key, a symmetric secret which encrypts the rest of the connection.

Once the parties have played an equal role in generating the shared secret key, they must authenticate themselves. The most common means of authentication is via SSH asymmetric key pairs. The server uses the public key to encrypt a message and send it to the client. If the client has the correct private key, they can decrypt the message and send it back to the server for verification.

Newest Version

As of this writing, the SSH protocol comes in two versions. The first version uses private RSA keys to decrypt challenges encrypted with the corresponding public key. But SSH protocol version 1 is limited in its support of message authorization codes, compression algorithms, and the algorithms necessary for key exchanges. By comparison, Version 2 of the protocol requires that the client sign a message and transmit the signature (not the message) with the public key used. The server then recreates the message and verifies the server. SSH version 2 is also not a monolithic protocol. 

The newest version is made up of a series of protocols that include improved public key certification, encryption standards, and even support for public key certificates.

In both versions, SSH keys serve a crucial function in protecting the involved parties’ information. It’s therefore in organizations’ interest to manage their SSH keys. That process involves safeguarding the keys that should be trusted and blocking those that shouldn’t.

(This post has been updated. It was originally published on February 5, 2019.) 

Related blogs

Best Practices for Securing SSH: Why Is It So Challenging?
4 Ways to Start Protecting Your SSH Keys
Oh SSH IT: Where Are Your SSH Keys?

All enterprises rely on Secure Shell (SSH) keys to authenticate privileged users and establish trusted access to critical systems, including application servers, routers, firewalls, virtual machines, cloud instances, and many other devices and systems. SSH keys are used for privileged administrative operations by system administrators, but are also used for secure machine-to-machine automation of critical business functions. Once SSH keys are put in place to enable client authentication, they enable ongoing, automatic connections from one system to another, without needing to enter a password.