SSH Hardening for Kubernetes Nodes

1. Introduction to SSH Hardening

SSH (Secure Shell) is the primary method for managing Linux servers, including Kubernetes nodes, securely and remotely. Misconfigured SSH can become an easy entry point for attackers. SSH hardening minimizes the risk of brute-force attacks, unauthorized access, and privilege escalation.

Example: A DevOps engineer managing EKS worker nodes with open root SSH access risks an attacker exploiting that entry point to compromise the entire cluster.

2. Why Harden SSH on Kubernetes Nodes?

• Attack Surface Reduction: Nodes run container workloads, so weak SSH settings can compromise the cluster.
• Least Privilege Enforcement: Restricting SSH ensures controlled, minimal access.
• Audit and Accountability: Logging SSH attempts helps detect unauthorized activity early.

3. Key Best Practices and Real-Time Examples

A. Disable Root Login

Why: Root access bypasses accountability and increases risk.

sudo vi /etc/ssh/sshd_config
PermitRootLogin no
sudo systemctl restart sshd

Example: Now, any attempt like ssh root@node-ip returns “Permission denied.”

B. Enforce Key-Based Authentication

Why: SSH keys are more secure than passwords.

ssh-keygen -t ed25519 -C "your_email@example.com"
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@node-ip

# On the node:
PasswordAuthentication no
ChallengeResponseAuthentication no
sudo systemctl restart sshd

Example: In production, admins use Ansible or Terraform to distribute keys automatically across all worker nodes.

C. Change the Default SSH Port

Why: Changing port 22 reduces brute-force attempts.

sudo vi /etc/ssh/sshd_config
Port 2222
sudo ufw allow 2222/tcp
sudo ufw reload
ssh -p 2222 user@node-ip

Example: After changing the port, bot attacks drop drastically in logs like /var/log/auth.log.

D. Limit Authentication Attempts and Set Idle Timeouts

Why: Prevents brute-force login attempts and disconnects idle sessions automatically.

MaxAuthTries 3
ClientAliveInterval 300
ClientAliveCountMax 0
sudo systemctl restart sshd

Example: If an admin forgets to close an SSH session, it automatically disconnects after 5 minutes of inactivity.

E. Restrict SSH Access by IP and User

# Restrict by IP:
sudo iptables -A INPUT -p tcp -s <trusted-ip> --dport 2222 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 2222 -j DROP

# Restrict by user:
AllowUsers adminuser kubeadmin

Example: Only CI/CD servers or on-call engineer laptops are whitelisted for SSH access.

F. Enable Two-Factor Authentication (2FA)

Why: Adds another security layer beyond SSH keys.

sudo apt install libpam-google-authenticator
google-authenticator
# Scan the generated QR code in Google Authenticator app

Example: Many enterprises enable PAM-based 2FA for bastion hosts managing Kubernetes nodes.

4. Real-Time Example Scenario

Let’s apply this to a real EKS setup running Ubuntu 22.04:

1. Disable Root Login: Admins connect as adminuser, blocking direct root logins.
2. Key-Based Authentication: Keys are stored in AWS Secrets Manager and pushed via automation.
3. Custom SSH Port: Port 2222 is used, drastically reducing attacks.
4. Monitoring: Logs like /var/log/auth.log are continuously monitored for anomalies.

tail -n 20 /var/log/auth.log
Oct 26 15:45:12 worker-node sshd[2456]: Failed password for invalid user test from 203.0.113.5 port 40312 ssh2
Oct 26 15:45:18 worker-node sshd[2456]: Connection closed by invalid user test 203.0.113.5 port 40312

5. Conclusion

SSH hardening is vital for securing Kubernetes nodes and ensuring cluster integrity. Disabling root logins, enforcing key-based access, changing default ports, and applying IP restrictions form the foundation of secure DevOps practices.

Modern managed Kubernetes services like AWS EKS and Google GKE implement these strategies at scale. Regular reviews of SSH configuration and continuous log monitoring are key to maintaining a strong security posture.