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