Introduction to SSH Hardening

In this article, we’ll explore practical SSH hardening techniques tailored for kubernetes nodes. These best practices help secure administrative access, minimize attack surfaces, and enforce strong authentication mechanisms. In this blog, I am going to share some real-time examples and configurations that you can apply to your Kubernetes worker and control-plane nodes. SSH provides direct administrative access. If it’s misconfigured, it becomes a high-impact attack vector.

SSH hardening focuses on reducing this attack surface by enforcing least privilege, strong authentication, and strict access controls. In production Kubernetes environments, this is not optional — it’s foundational security hygiene.

Why Harden SSH on Kubernetes Nodes?

Attack Surface Reduction: Kubernetes nodes host container workloads. Weak SSH settings (default port, password login, root access) allow attackers to compromise the node and laterally move inside the cluster.
Least Privilege Enforcement: Restricting SSH ensures only authorized admin actions are executed, reducing blast radius.
Audit and Accountability: Hardened SSH configurations integrate cleanly with logging and SIEM pipelines for real-time monitoring.

Key Best Practices with Real-Time Examples

A. Disable Root Login

Direct root access via SSH bypasses accountability and is a common attacker target. The robust approach is to use a non-root user with sudo privileges.
Please follow below steps to disable root login:
1. Edit the SSH configuration file /etc/ssh/sshd_config on the node
2. Set PermitRootLogin to no
3. Restart the SSH service

					sudo vi /etc/ssh/sshd_config

					PermitRootLogin no

					sudo systemctl restart sshd

Result:

					ssh root@node-ip

					Permission denied, please try again.

B. Enforce Key-Based Authentication and Disable Password Logins

Passwords are brute-force friendly. SSH keys are not. Key-based authentication is the gold standard for secure SSH access and provides a cutting-edge security baseline with minimal operational overhead.
Please follow below steps to enforce key-based authentication:
1. Generate an SSH key pair on your local machine using ssh-keygen
2. Copy the public key to the Kubernetes node using ssh-copy-id
3. Edit the SSH configuration file /etc/ssh/sshd_config on the node
4. Set PasswordAuthentication to no
5. Restart the SSH service

						ssh-keygen -t ed25519 -C "your_email@example.com"

						ssh-copy-id -i ~/.ssh/id_ed25519.pub user@node-ip

						PasswordAuthentication no

						sudo systemctl restart sshd

C. Change the Default SSH Port

This doesn’t replace proper security controls, but it significantly reduces noise from automated scanners and botnets.

						Port 2222

						sudo ufw allow 2222/tcp

						sudo ufw reload

ssh -p 2222 user@node-ip

D. Limit Authentication Attempts and Idle Sessions

We can limit the authentication attempts and idle sessions to prevent Brute-force protection and idle timeouts are small changes with big security impact. This is especially important on shared admin bastions.

						MaxAuthTries 3

						ClientAliveInterval 300

						ClientAliveCountMax 0

- MaxAuthTries 3 limits login attempts to 3
- ClientAliveInterval 300 sends a keepalive every 300 seconds
- ClientAliveCountMax 0 disconnects idle sessions immediately

E. Restrict SSH Access by IP and User

We can restrict SSH access by IP and user to ensure only trusted identities can even attempt access.

						sudo iptables -A INPUT -p tcp -s <trusted-ip> --dport 2222 -j
						ACCEPT

						sudo iptables -A INPUT -p tcp --dport 2222 -j DROP
					

AllowUsers adminuser kubeadmin

F. Enable Two-Factor Authentication (Optional)

For high-security environments, adding MFA via PAM modules such as Google Authenticator adds another strong layer of defense.

Real-Time Example: EKS Worker Nodes

Imagine managing an Amazon EKS cluster running Ubuntu 22.04 worker nodes. SSH access is restricted to a hardened bastion host.

Root login disabled using PermitRootLogin no
Password authentication fully disabled
SSH port changed to 2222
UFW restricts access to office VPN IPs
Logs monitored via /var/log/auth.log

tail -n 20 /var/log/auth.log

Conclusion

SSH hardening is a foundational security control for Kubernetes nodes. These configurations dramatically reduce attack vectors while maintaining a seamless operational experience for platform teams.

In real-world environments like EKS, GKE, or self-managed clusters, small SSH configuration changes deliver outsized security gains. Review these settings regularly, automate them via cloud-init or Ansible, and treat SSH as critical infrastructure — because it is.

SSH Hardening for Kubernetes Nodes