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:
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.
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.
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
Phase 2: Authentication of Client
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.
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.
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.
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.
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.