SSL Certificates Scale Better Than SSH?

 What is SSH?

• SSH (Secure Shell) is a cryptographic protocol that allows you to securely connect to remote systems (like Linux servers).

• It encrypts traffic, so commands, passwords, and files sent over the network cannot be intercepted.

• Default port: 22.

• 
  

What are SSH Keys?

• SSH can use username & password or key-based authentication.

• 
  

• SSH keys are a more secure alternative to passwords. They use public-key cryptography:

• 
  

  • Private key → kept safe on your machine.

  • Public key → copied to the remote server (~/.ssh/authorized_keys).

  • 
    

• When you try to connect, the server checks if your private key matches the public key.

• 
  

How to Implement SSH Keys (Step by Step)

1. Generate SSH keys on your local machine:

   ssh-keygen -t rsa -b 4096 -C "your_email@example.com"

   • This creates two files in ~/.ssh/:

     • id_rsa (private key)

     • id_rsa.pub (public key)

2. Copy public key to server:

   ssh-copy-id user@server_ip

   OR manually:

   cat ~/.ssh/id_rsa.pub | ssh user@server_ip "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

3. Login without password:

   ssh user@server_ip

   (Now it uses your private key.)

4. (Optional) Disable password authentication on the server for extra security:Edit /etc/ssh/sshd_config:

   PasswordAuthentication no

   Then restart SSH:

   sudo systemctl restart sshd

   
   

Where to Use SSH Keys

• Admin access to Linux servers.

• Automation: scripts, Ansible, Terraform, Jenkins, GitHub Actions.

• File transfers: scp, rsync, SFTP.

• Tunneling/port forwarding securely.

• Git operations (GitHub, GitLab, Bitbucket can use SSH keys to authenticate instead of username/password).

• 
  

Use Cases of SSH Keys

1. Sysadmin / DevOps

   • Login securely into servers without managing passwords.

   • Manage clusters of servers with automation tools.

2. CI/CD Pipelines

   • Jenkins/GitHub Actions connect to servers via SSH keys to deploy apps.

3. Version Control (Git)

   • Push and pull code from GitHub/GitLab using SSH authentication.

4. Secure File Transfer

   • Use scp or sftp with SSH keys to move data between servers.

5. Tunneling / Proxying

   • Forward ports securely (e.g., access database behind a firewall).

Why SSL Certificates Scale Better Than SSH

We DevOps and Cloud Engineers use SSH and SSL every day, but for very different reasons.

SSH is how we log into servers. It's authentication and remote shell access. You generate a keypair with ssh-keygen, copy the public key to the server, and you're in.

SSL is how we secure services. It's encryption and identity for traffic between browsers, APIs, and services enabled using certificates like those from Let's Encrypt or AWS ACM.

In a typical SSH setup, every user has a keypair, and the server stores public keys. If you’ve worked on legacy fleets or unmanaged clusters, you know what’s coming: SSH key sprawl.

I saw a case where 8 engineers were rotating on-call duties. Over time, they accumulated 45 public keys across 30 EC2 instances. Some belonged to interns who had left. Some were from CI runners we no longer used. No expiry, no labels, no audit.

Worse, people were doing ssh-copy-id directly or using Ansible with inventory files that were never cleaned.

To clean it up, they had to:

Run find ~/.ssh/authorized_keys on every node

Build an internal tool to map keys to owners based on fingerprints

Rotate all keys using ssh-keygen -R and centralized provisioning via SSH certificates

It was a mess. And we swore to never let SSH become the main trust system again.

When we switched to ALB-based apps on AWS, we used ACM certificates for TLS termination. The setup was a one liner in Terraform:

listener {

port = 443

protocol = "HTTPS"

ssl_policy = "ELBSecurityPolicy-TLS13-1-3-2021-06"

certificate_arn = aws_acm_certificate.app_cert.arn }

The certs renewed automatically. Zero manual rotation.

Here’s the kicker: SSL certificates expire by design, are traceable, and bind to services, not users. That makes them scalable.

If you’re building for scale, use SSL for service-to-service, client-to-server, or browser-to-backend.