What are SSH keys?

1. What is SSH?

Secure Socket Shell (SSH), also known as simply Secure Shell, is a cryptographic protocol, primarily used to enable secure access to remote servers and devices over the internet. It operates on public key cryptography that provides a mechanism for mutual authentication between the server and the client and establishes an encrypted channel of communication between them over an unsecured network.

SSH is widely used to enable the following functions:

1. Secure access to remote systems 
2. Secure execution of commands on remote systems
3. Secure remote delivery of software updates 
4. Secure interactive and automated file transfers
5. Auto-login to servers
6. Secure management of critical network infrastructure systems such as routers, firewalls, servers, virtual machines, operating systems and more. 

SSH is usually enabled on most operating systems. It is enabled by default on Linux, Unix, and Mac OS. SSH connections can be initiated directly through the terminal program. However, on Windows OS, SSH connections must be initiated with an SSH client program. Some of the popular client program available today are puTTY, wolfSSH, and SecureCRT.  

• • 1. What is SSH?
  • 2. What are SSH keys?
  • 3. How does SSH work?
  • 4. SSH vs. SSL/TLS certificates – what’s the difference?
  • 5. Application of SSH
    • 5.1. Risks of use
    • 5.2. Best Practices for key management

2. What are SSH Keys?

SSH keys are a pair of public and private keys that are used to authenticate and establish an encrypted communication channel between a client and a remote machine over the internet.

3. How does SSH work?

SSH works on a client/server model, where the ‘SSH client’ is a piece of software on the user’s system that can communicate with the remote host, and the ‘SSH server’ is the remote host that provides access via secure SSH connection. 

For a client to initiate and establish a secure connection with a remote server, it leverages three different encryption technologies—symmetric encryption, asymmetric encryption, and hashing. 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.

4. 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.

SSL is primarily used to secure connection between a website and a web server. SSH is used to establish a secure connection between two remote systems over the internet. 

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 contrary, 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.

Another major difference between SSH and SSL/TLS is that establishing an SSH connection requires both the client and server to mutually authenticate themselves with their public and private key pairs, respectively. But in the case of SSL/TLS connection, only the server needs to authenticate itself to the client with its public and private key pair. The client does not have to prove its authenticity to the server. Simply put, SSH users are privileged users authorized to access remote systems and must prove their authenticity to the server to get access. With SSL, everyone visiting the website is allowed to interact with the server. They don’t have to authenticate themselves. 

5. Using SSH in your organization

5.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.

5.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.