IT and security teams use Secure Shell (SSH) to safeguard administrative access and automated processes for machines in their organizations. However, recent trends in digital transformation have spurred tremendous growth in the number of machines that organizations rely on.
These new developments push IT system administrators to aspire to new levels of productivity via automation. Many administrators achieve this productivity by creating and deploying SSH keys, which establish fast, secure, automated connections to critical assets.
Defining SSH machine identities
SSH is a cryptographic network protocol that gives users—particularly system administrators—a secure way to access machines over an unsecured network. SSH provides strong authentication and encrypts data communications between two machines connecting over an open network such as the internet. System administrators use SSH to perform remote administration for nearly all systems, to automate operations, and to transfer files between systems.
The SSH protocol comes in these versions:
- SSHv1: The first version uses private Rivest–Shamir–Adleman (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. Since 1998, risks with SSHv1 have been known. And even after all this time, you’d think SSHv1 wouldn’t persist in enterprises, but it does. This may be a result of administrators not upgrading to the latest version of OpenSSH, not disabling SSHv1, or possibly believing that legacy applications “need” it to function.
- SSHv2: 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. SSHv2 is also not a mono- lithic protocol — it’s made up of a series of protocols that includes improved public key certification, encryption standards, and even support for public key certificates.
- OpenSSH: This open-source implementation of the SSH protocol is freely available and is delivered as a source code.
In all versions, SSH keys serve a crucial function in protecting the information that your organization values most. Therefore, it’s in your best interest to effectively manage SSH keys.
Recognizing how SSH machine identities work
SSH encrypts data exchanged between two parties by 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 on what protocols they support.
During the connection process, SSH leverages two types of SSH keys as machine identities:
- Host keys: SSH uses host keys to guarantee the authenticity of the server and create the encrypted tunnel.
- Authorized keys: SSH users can place authorized keys on the server to grant them access without using passwords, which simplifies day-to-day work. This method is commonly referred to as public key authentication.
Both host and authorized keys work in public-private pairs and must be administered together with a slew of security options (config files) such as the encryption algorithm, access levels, port forwarding, key length, and passphrase.
When a system administrator executes an SSH command, the SSH client and server engage in six steps:
- Send a connection request.
- Authenticate back to the client by using the unique server host SSH key.
- Set up an encrypted channel.
- Authorize session access by using passwords or public key authentication.
- Submit a session info request by executing shell commands.
- Return session info when the SSH server sends the command return data back to the client.
How SSH machine identities are used
Built into most operating and network systems, SSH has become the de facto interface standard for remote system access. SSH popularity is due largely to its security features, versatile usage, and baked-in automation. After SSH keys are put in place to enable client authentication, they can enable ongoing, automatic connections from one system to another, without needing to enter a password. Today, this broadly adopted cryptographic protocol is used by a majority of system administrators as well as many automated processes.
How can system administrators use SSH in your organization?
- Securing privileged access
SSH is often used to safeguard administrative access for organizations—securing system-administrator-to-machine access for routine tasks. SSH keys ensure that only trusted users and machines have access to sensitive network systems and data. Administrators rely on SSH as an encrypted protocol to authenticate privileged users, establish trusted access, and connect administrators and machines.
You may be surprised how many systems in your organization rely on SSH keys for privileged administrative access and secure machine-to-machine automation. The short list includes application servers, routers, firewalls, virtual machines, cloud instances, and other devices and systems that leverage SSH. Like most large organizations, you’re probably using SSH with thou- sands of systems.
- Automating routine processes
The SSH protocol is multifaceted and encompasses many functions, which have been adopted by a wide variety of automation tools. SSH is also used to secure the machine-to-machine automation of critical business functions, such as automatically triggering operations and routine file transfers. SSH keys ensure that only trusted users and machines have access to sensitive network systems and data.
- Controlling cloud access
Cloud servers often have SSH enabled for remote administration and maintenance of servers. SSH is widely used in cloud environments because of the encrypted communication channel it provides the client and server. An SSH keypair may be generated by the cloud provider, delivering the private key to the user and retaining a copy of the public key. The public SSH key is used to generate an administrator password or used directly for logging into a virtual machine. Private SSH keys can be exposed when they’re accidentally, insecurely, or publicly stored in the cloud.
- Securing DevOps
Development operations (DevOps) teams focus on speeding up the delivery of products and services. To do this, developers need access to cloud-based, self-contained runtime environments, known as containers, to run individual modules called microservices. This access is often secured by SSH machine identities.
In the fast-paced world of DevOps, traditional SSH controls may not be able to cope with new environments and can slow the delivery of IT services. The resulting frustration can cause developers to avoid encryption altogether, take shortcuts with SSH keys, or otherwise skimp on the security of machine identities. When this happens, it exposes your organization to unnecessary security vulnerabilities.
Start managing your SSH keys with Venafi today
Venafi protects machine identities for the largest companies on earth, securing cryptographic keys and digital certificates that authorize all machine-to-machine connections and communications.
Now that you understand how exactly SSH machine identities work, it’s time to gain full visibility on all SSH keys across your network. Venafi SSH Protect will allow you to achieve this and much more.