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.
SSH is a cryptographic network protocol that gives users a secure way to access a computer over an unsecured network. SHH keys allow for data to be encrypted between two computers that are connected over an open network. Enterprises use SSH to provide secure access for users and automated processes, automate file transfers, issue remote commands, and manage network infrastructure
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.
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.
Enterprise organizations have thousands of SSH connections — each one with the potential to lead to a security breach if not protected. Make sure you know where your SSH keys are stored to avoid failing SSH audits and costly fines. Download this brief to learn how your organization can reduce SSH risks.
(This post has been updated. It was originally published on February 5, 2019.)