Beyond SSH Keys: Authentication using SSH Certificates - Security Boulevard

Beyond SSH Keys: Authentication using SSH Certificates

Beyond SSH Keys: Authentication using SSH Certificates

Secure Socket Shell, or SSH, has been in use for decades. It’s come to be known as the de-facto method by which data in-motion was encrypted, and also how access to remote systems was authenticated on both the client’s and the server’s side. In short, they’re a great way to access a machine over an unsecured network, such as the open internet. Using strong password authentication and encrypted communications, it enables network administrators to manage systems/applications remotely – by allowing them to log into a remote computer, move files between computers, and execute commands on them.

Their benefits notwithstanding, SSH Key-based authentication is not perfect.

They’re not easy to use. SSH Keys are not governed by established protocols and processes, but are generated and used on demand. This makes the user experience clunky at best and confusing at worst.

They’re not 100% secure in practice. While the concept of SSH-key-based authentication is an airtight one, it is only airtight on paper. In reality, its perfectness is marred by insecure management methods and shortcuts that compromise the integrity of this method. Key exposure, key reuse, and theft of discarded keys are common problems admins run into, and that’s just the tip of the iceberg.

They cannot scale easily. When the number of SSH keys balloon, admins have a real problem on their hands in the form of key sprawl. Cleaning up scattered, discarded keys can cost SSH operators significant amounts of time.

However, this doesn’t mean SSH is a risk in itself. The technology is perfect, but the execution often leaves much to be desired (unless SSH keys are impeccably managed).

Fortunately, there’s a solution.

Enter SSH Certificates.

Simply put, SSH Certificates deliver the best of both worlds – SSH Keys and x.509 certificates. They’re a relatively new introduction to the PKI mix, but by no means are they hot on the shelves – yet, they aren’t used as much as they should be, given their immense usefulness.

While SSH Key-based authentication uses public key cryptography to operate, SSH Certificate-based authentication simply attaches a signed certificate to each key to verify their identities.

In essence, SSH certificates do away with old-school password-based SSH verification processes. By using a certificate that is signed by a trusted Certificate Authority, users can do away with the passwords (which are not secure, given that passwords can either be stolen or cracked via brute force), and leverage a partially automated trust-based certificate authentication process to gain access to systems.

Are they perfect?


While SSH Certificates seal the security gaps that are prevalent in SSH Key-based authentication techniques, using them isn’t child’s play. Creating an SSH certificate involves transferring public keys, getting them signed by CAs, and returning them to the user. Not only are these processes manual, they also expose themselves to human error or misuse by virtue of the human intervention involved. What’s more, configuration files often need to be modified to accommodate and accept these SSH certificates, which adds another layer of complication to the process.

If only there were a way to streamline and automate this workflow and render SSH Certificates supremely easy to use, and eliminate the possibility of human error, to boot.

AppViewX’s SSH Certificate Platform

AppViewX has been helping customers manage, rotate, and automate the operations of PKI certificates and keys for years. The platform imbibes the same concepts and applies them to SSH certificates, automating and simplifying most of the processes involved in creating and using these certificates.

For instance, if you wanted to create a host group and add users to this group in order to use SSH certificates with, you could simply use one of our pre-built workflows to carry out the entire process for you. AppViewX would create an enterprise host group with all the servers in an organization and provide host certificates to every server. The public key of the host server would be copied to the CA server, which would then be signed by the CA, and then transferred back to the host servers. Then, the host’s sshd_config file would be updated with the new host’s name, the sshd service’s status would be checked, and then restarted.

Here are some other tasks you’d be able to automate with AppViewX:

  • Create Host Group and Add Hosts
  • Add or Remove Hosts to Host Group
  • Create Host Access Group and Add Hosts
  • Add or Remove Hosts to Host Access Group
  • User Request Access to Host Access Group and Client Group
  • Add or Remove Clients to Client Machine Group
  • Revoke SSH Certificate for Host or User
  • SSH Policy Compliance Check and Enforcement

There’s a lot more where those came from!

If you’re an SSH Key user who is looking for a better, simpler, and more secure method to use them within your organization, you should consider SSH Certificates as a possible alternative.

And if you already use SSH Certificates, automating certificate operations would be the next big step you could take to elevate your security to the next level. Of course, you’d also save countless hours’ worth of manual effort, and eliminate the possibility of downtime and compliance fines caused by human error.

Regardless of whether you’re just getting started with PKI, or a user of SSH keys, or someone who is already using SSH certificates (and would like to supercharge your experience with automation), AppViewX can lend you a hand. Get on a call with us, and our solution engineers can figure out how exactly we can be of assistance. Either book a personalized demo, or join our scheduled demos every Thursday of every week.

Happy SSHing!

The post Beyond SSH Keys: Authentication using SSH Certificates appeared first on AppViewX.

*** This is a Security Bloggers Network syndicated blog from Blogs – AppViewX authored by AppViewX. Read the original post at: