How Secure Shell (SSH) Keys Work
Fri, 08/05/2022 – 00:05
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 through several data manipulation techniques. It uses symmetric encryption system like AES, Blowfish, 3DES, CAST128 and Arcfour to encrypt the entire connection, asymmetric encryption during the initial key exchange process to configure symmetric encryption and for authentication based on the key, and the hash to generate hash. based on message authorization codes (HMAC) that ensure that the integrity of a received message is intact.
Like Justin Elingwood from DigitalOcean Explain, SSH encrypts data exchanged between two parties using a client-server model. The server listens on a designated port for connections, while the client is responsible for the Transmission Control Protocol (TCP) handshake with the server. This initial connection sets the stage for the server and client to negotiate session encryption based on the 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 seed and cipher generator (such as AES) along with a public key. Their private key, the other party’s public key, and the seed form the basis of the shared secret key, a symmetric secret that encrypts the rest of the connection.
Once the parties have played an equal role in generating the shared secret key, they must authenticate. The most common means of authentication is to use 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, it can decrypt the message and send it back to the server for verification.
As of this writing, the SSH protocol comes in two flavors. The first version uses private RSA keys to decrypt challenges encrypted with the corresponding public key. But version 1 of the SSH protocol is limited in its support for message authorization codes, compression algorithms, and algorithms needed for key exchanges. By comparison, version 2 of the protocol requires the client to 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 most recent version is made up of a series of protocols that include enhanced public key certification, encryption standards, and even support for public key certificates.
In both versions, SSH keys perform a crucial function in protecting the information of involved parties. It is therefore in the interest of organizations to manage their SSH keys. This process involves protecting keys that should be trusted and blocking those that shouldn’t.
(This post has been updated. It was originally released on February 5, 2019.)
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 administrative operations privileged by system administrators, but are also used for secure machine-to-machine automation of critical business functions. Once SSH keys are in place to allow client authentication, they allow continuous and automatic connections from one system to another, without the need to enter a password.
*** This is a syndicated blog from the Security Bloggers Network of Blog RSS written by Scott Carter. Read the original post at: https://www.venafi.com/blog/how-secure-shell-ssh-keys-work