Let me let you into a little secret: 96% of the world’s servers are Linux servers. What most of these billions of servers have in common is that they are all managed through SSH. While these servers have most of the critical information for the organization, their security is usually overlooked because most organizations are just continuing to use the same security they used 20 years ago. This is unacceptable in this zero-trust world.
Over the past few years, hackers have noticed this gap in security and the impact compromising one of these servers can have, from the LinkedIn hack that lead to many compromises of other companies, to the T-Mobile data breach from last year that cost T-Mobile over $350 million dollars in restorations. In a study last year, we gathered that there are over 2.5 million SSH brute force attempts per server per year.
While SSH Keys might sound like a secure option for SSH, an average server has 50-200 keys and 90% of them are not used. This opens the door for attackers to find one of those keys and be able to access the endpoints, such as, ex-employee who gains access to your the endpoints and disrupts your services as in a similar attack to the one Cisco suffered in 2018.
When SSH was designed, extra SSH Keys in a server with no expiration date were not a problem because there was a strong network perimeter that required you to be physically in the office connected to a computer that was physically connected to the network. With todays distributed workforce this is no longer the case, users are connecting from all around the world from networks and devices that are not controlled and managed by your organization, shifting the security perimeter to a shared responsibility of strong identity and network security.
SSH keys are great, they use the latest cryptographic algorithms which makes them practically impossible to brute force. However, they are hard to manage, SSH keys must be manually added and remove from servers and users are responsible for the security/protection of the private key. To remediate the growing security risk these two problems created, OpenSSH created SSH certificates. SSH certificates have the same security properties as an SSH key but can be centrally trusted by adding the Certificate Authority as a trusted issuer, and do not have to remove the keys since they have an expiry date. This dramatically reduces the management overhead and surface area of each key.
While centrally managed certificates are the solution, they must be manually issued by the Certificate Authority administrator learn how to create your SSH Certificate Authority. At Keytos our goal is to make the secure way easier than the insecure way, this is why we leverage your existing SSO corporate identity and all the security features you have enabled and transfer it to SSH by creating short term (1 hour to 1-week certificates) giving users just in time access to your SSH endpoints. This enhances the SSH certificate security by removing the responsibility of protecting the private key from the user and transferring the trust to your corporate identity.
