Skip to main content
banner image
venafi logo

How Secure Shell (SSH) Keys Work

How Secure Shell (SSH) Keys Work

February 5, 2019 | David Bisson

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.

How easily can SSH keys spin out of control in your organization? Read more. 

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. According to Sararth Pillai of /Root, 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.

Do you actively monitor all your keys?

Learn more about machine identity protection. Explore now.  


Related blogs

Like this blog? We think you will love this.
infographic of three businessmen running from one businessman with a ticking time bomt
Featured Blog

5 Steps that May Be Leading You toward a Ticking SSH Bomb

Here 5 signs that your SSH environment may have a ticking SSH bomb:

Read More
Subscribe to our Weekly Blog Updates!

Join thousands of other security professionals

Get top blogs delivered to your inbox every week

See Popular Tags

You might also like

CIO Study: Certificate-Related Outages Continue to Plague Organizations
White Paper

CIO Study: Certificate-Related Outages Continue to Plague Organizations

Forrester Consulting Whitepaper: Securing the Enterprise with Machine Identity Protection
Industry Research

Forrester Consulting Whitepaper: Securing the Enterprise with Machine Identity Protection

Machine Identity Protection for Dummies

Machine Identity Protection for Dummies

About the author

David Bisson
David Bisson

David is a Contributing Editor at IBM Security Intelligence.David Bisson is a security journalist who works as Contributing Editor for IBM's Security Intelligence, Associate Editor for Tripwire and Contributing Writer for Gemalto, Venafi, Zix, Bora Design and others.

Read Posts by Author
get-started-overlay close-overlay cross icon
get-started-overlay close-overlay cross icon
Venafi Risk assessment Form Image

Sign up for Venafi Cloud

Venafi Cloud manages and protects certificates

* Please fill in this field Please enter valid email address
* Please fill in this field Password must be
At least 8 characters long
At least one digit
At last one lowercase letter
At least one uppercase letter
At least one special character
* Please fill in this field
* Please fill in this field
* Please fill in this field

End User License Agreement needs to be viewed and accepted

Already have an account? Login Here

get-started-overlay close-overlay cross icon

How can we help you?

Thank you!

Venafi will reach out to you within 24 hours. If you need an immediate answer please use our chat to get a live person.

In the meantime, please explore more of our solutions

Explore Solutions

learn more

Email Us a Question

learn more

Chat With Us

learn more