What are SSH keys?

What is SSH?

Secure Socket Shell (SSH), also known as simply Secure Shell, is a cryptographic protocol that leverages public key cryptography to operate. It’s primary purpose is to secure remote private transactions over the internet by providing authentication on both the server-side and the client-side in order to establish an encrypted channel between both communicating parties. Some typical areas where SSH key-based authentication is applied are:

• Remote logins into secure systems
• System-to-system file transfer
• Auto-login for server access

One of the biggest advantages of using SSH keys is their resilience against cyber exploits – brute force attacks, for instance. This is because the SSH protocol does not require passwords to be exposed over the web. This is one of its biggest strengths over its predecessors (Telnet, rlogin, rexec etc.) since these protocols required passwords to be transmitted as plain text, rendering them vulnerable to interception.

• 1. What is SSH?
• 2. How does SSH work?
  • 2.1. SSH vs. SSL/TLS certificates – what’s the difference?
  • 2.2. The working of SSH keys
• 3. Application of SSH
  • 3.1. Risks of use
  • 3.2. Best Practices for key management

2. How does SSH work?

2.1. SSH vs SSL/TLS certificates – what’s the difference?

Asymmetric encryption is a key component of both SSH keys and SSL/TLS certificates (x.509 certificates). While their means of operation might be similar, they work in completely different ways.

x.509 certificates require the key pairs used in the asymmetric encryption process to be affixed with a digital certificate, which has the digital signature of a trusted issuing body (Certificate Authorities, or CAs). Without a certificate accompanying the public key, SSL/TLS protocols cannot be safely used over the internet.

On the other hand, SSH key-based authentication leverages both symmetric and asymmetric encryption. What’s more, the use of SSH keys is not governed or regulated by a central body. They are generated, distributed, and used strictly by the transacting parties involved.

An important advantage SSH has over SSL/TLS is the fact that it enables highly secure remote access to servers and devices. On the other hand, x.509 certificate-based authentication would have to be deployed alongside other protocols like FTP (File Transfer Protocol) to achieve that level of functionality. This is an expected limitation, since x.509 certificates provide security for extremely high traffic volumes which usually do not require such specialized functionality (for instance, visitors on a shopping website), while SSH keys are used only within or between IT/security teams of organizations.

2.2. The working of SSH keys

SSH works on a client/server model, where the ‘SSH client’ is the system that requires remote access, and the ‘SSH server’ is the one that provides it, thus creating a secure channel by use of Secure Shell keys. There are several SSH client programs available today (puTTY, wolfSSH, and SecureCRT are some popular ones) which can be used based on the platform they is required for.

For a client to initiate and establish a secure connection with an SSH server, it leverages both symmetric and asymmetric encryption. The general process is detailed below, and takes place over two phases.

Phase 1: Shared Secret Generation

1. A TCP handshake is initiated by the client, during which it verifies its identity to the server and both parties agree on the encryption protocols to be followed.
2. The server presents its public key to prove its identity to the client.
3. A ‘session key’ is mutually created by both parties using the Diffie-Hellman algorithm, which will be used to encrypt the entire sesion. Here, public and private data from the both server and client are combined to create this session key or ‘shared secret’, which is a symmetric key (i.e the same key can be used to encrypt and decrypt information)
4. Symmetric encryption is established by means of the session key, which secures the transaction against external interception.

Phase 2: Authentication of Client

1. The server authenticates the client, either by means of receiving an encrypted password, or via SSH keys. Since passwords are less secure than SSH keys due to their vulnerability to brute force attacks, the use of the latter is recommended.
2. The SSH key-based authentication begins with the client informing the server of the credentials of the key pair it would like to authenticate itself with. In this case, both the server and the client have corresponding public keys.
3. The server verifies the existence of this key pair in its database, and then uses its public key to encrypt a message, and sends it to the client.
4. The client decrypts the message with its corresponding private key, and then combines the underlying value with the session key to create a hash value.
5. It sends the hash value back to the server.
6. The server receives this hash value, and then creates its own hash value (using the original unencrypted message and the shared session key). If both hash values match, the server takes it as proof that the client is the owner of the private key, and grants it authentication.
7. Once authentication is established, both parties open up an encrypted channel to communicate with each other.

3. Using SSH in your organization

3.1. Risks of Use

Since there is no governing body to regulate the use of SSH keys, there is a component of uncertainty-based risk involved. SSH Keys are generated on an ad-hoc basis, creating the possibility of key sprawl (i.e several keys might be discarded and left unmanaged once they are no longer of use). What’s more, a lack of defined management processes for SSH credentials means that there is no concrete inventory. Large organizations usually possess significant quantities of SSH keys on file – left unmanaged, they could become potential back-doors into a network, or targets for data theft or breaches.

Another key process that has to be monitored is key rotation. Stale keys present weak links in the form of inadequately strong passwords and obsolete algorithms, which can be exploited for gain by hackers.

3.2. Best Practices for Key Management

Policy enforcement, audit control, and visibility into the SSH key repository are some of the recommended best practices for bettering the security posture of an organization with respect to their PKI.

Obtain Visibility:

Periodically scan your network with a discovery tool to locate and inventory SSH keys. Then, map them to their respective endpoints, and affix them with the necessary operational information, such as passwords, for easy access by an administrator.

Rotate Keys:

Stale SSH keys, if accessed, are vulnerable to passcodes hacking, and thereby, network infiltration. Define policy that mandates regular generation, re-keying, and rotation of SSH keys, and notify stakeholders of the same. Passcodes, if used, must not be reused – the process of key rotation may be automated in order to reduce the risk margin associated with manual rotation.

Audit and Enforce Policy:

Create and enforce organization-wide policy for security/IT teams to adhere to. Maintain strict audit trails to gain transparency into the access, modification, and use of each SSH key and credential.

Control Access via Permissions:

Leverage directory services to assign privilege-levels and roles for all members of the concerned teams. This way, only team members with the required level of clearance can modify SSH credentials, allowing for better trackability, and will also minimize undocumented keys or unapproved modifications.

Avoid hard-coding of keys:

Eliminate the practice of hard-coding SSH keys into software applications. This is risky, since a weak password could expose the entire application to cyber exploits. Furthermore, remediating this vulnerability is made difficult by hard-coded keys as well. Use centrally managed systems to handle SSH processes, assisted by role-based control.