Of course we cannot always share details about our work with customers, but nevertheless it is nice to show our technical achievements and share some of our implemented solutions.
SSH (Secure Shell) access remains the backbone of infrastructure management for developers and DevOps teams. But with highly distributed teams across the globe and mobile access, there are increased challenges of securing SSH access yet allowing quick access to so-called road warriors.
In this blog post we describe how we used Knocknoc to ensure security with proper authentication and authorization - yet allow an automated access for our customer's developers.
In the traditional (and in our point of view obsolete) IT world, a developer would be working inside the premises of the organization, using the organization's Internet access to connect to remote servers. The administrator of the remote server(s) would create firewall rules to allow the corporation's public IP address to access the server's SSH.
But the world works differently today. Developers and DevOps engineers can work in distributed teams across the globe, work from remote locations, work from home, work while being on the road (mobile road warriors). With ever-changing public IP addresses, sometimes multiple times per day, updating the firewall rules has become cumbersome and slow.
"What about allowing everyone (0.0.0.0/0) to access SSH on the remote servers? We only allow key authentication - that should be safe, right?"
Although this sounds tempting and eliminates the administrative work of updating the firewall rules, the remote servers are exposed to potential vulnerabilities and exploits attacking these vulnerabilities. Although SSH is one of the most robust and secure server applications, there is not a 100% guarantee that a hacker or automated script couldn't exploit a weakness and gain access on the server.
"What if we could automate the firewall rules after a proper authentication?"
This is the moment we became aware of Knocknoc.
Enter Knocknoc: a central authentication and authorization gateway designed to simplify access control, integrate with enterprise identity providers, and enforce multi-factor authentication (MFA) policies.
Knocknoc acts as an intelligent gateway between developers and your infrastructure. Instead of connecting directly to a server, developers authenticate through Knocknoc - which then authorizes and brokers the connection on their behalf.
Key features of Knocknoc include:
As Knocknoc features SSO integration and our customer already uses Microsoft EntraID for centralized user and group management, we configured the corresponding EntraID groups in Knocknoc and added these groups to the relevant backend services. In our case we created multiple services to separate SSH environments, allowing the customer's EntraID administrator to control user access to non-production and production environments.
Furthermore we adjusted the SSH access to go through a so-called SSH Bastion Host (also known as SSH Jump Host). This Bastion Host serves as central SSH gateway for all servers within an environment. Public access to this SSH Bastion Host is blocked - except when a user successfully authenticated in Knocknoc.
And this is how it works:
1) The developer opens the custom Knocknoc URL in the browser and uses SSO Login. The login effectively happens on the configured SAML Provider - which is EntraID in this situation. As the EntraID policy requires 2FA, the developer authenticates with user credentials and an additional device or authenticator app. Once successfully logged in, the user can see the session duration and which services the user is now granted to access.
2) In the background, the Knocknoc server contacts the knocknoc agent on the server(s) behind the granted services and executes the "knocker". In our case the knocker is a script which automatically adds the public IP of the authenticated user into an ipset (firewall group); therefore granting the user access to the otherwise blocked SSH port.
3) The user now connects to the SSH Bastion Host from the command line, using a personal SSH user and password-protected SSH key for SSH authentication.
The user's IP address is automatically removed from the firewall rule once the Knocknoc session expires. The session duration can be defined on multiple levels, for example on service level, to reduce the time window of allowed access from the user's IP address to the SSH server.
After the successful implementation of Knocknoc as central authentication and authorization gateway, we achieved something rare: Everyone involved was happy: