Before AWS SSM, This Is How We Reached Servers

Most developers use SSH long before they understand what’s happening underneath.

You type:

ssh -i my-key.pem ec2-user@54.x.x.x

A terminal opens.

Commands work.

Magic.

But under the hood, SSH is doing a carefully choreographed security handshake.

Let’s unpack it.

Step 1: You Initiate the Connection

It starts from your machine.

Your laptop reaches out to the server:

Your Laptop  --->  EC2 Instance

Usually on:

TCP Port 22

This immediately tells us something important:

The server must be reachable.

Which means:

• public IP OR VPN/private route
• firewall allows port 22
• security groups permit access
• network path exists

Already, infrastructure complexity enters the picture.

Step 2: The Server Says, “This Is Me”

The server responds with its host key.

Think of this like identity proof.

The server says:

“I claim to be the machine you’re trying to reach.”

Your SSH client checks:

~/.ssh/known_hosts

If the server is known, connection continues.

If not, you see:

The authenticity of host can't be established.
Are you sure you want to continue connecting?

This is SSH protecting you from impersonation attacks.

Without this step, an attacker could pretend to be your server.

Step 3: Cryptographic Handshake Begins

Now both sides negotiate encryption.

They agree on:

• encryption algorithm
• key exchange method
• session encryption keys

This creates a secure encrypted tunnel.

At this point:

Even if someone intercepts traffic…

they see encrypted noise.

Step 4: Authentication Happens

Now the server asks:

“Prove who you are.”

This is where your private key comes in.

Example:

ssh -i my-key.pem ec2-user@54.x.x.x

Your machine uses:

my-key.pem

to cryptographically sign a challenge.

Important:

Your private key is never sent to the server.

Instead:

• server sends challenge
• your client signs it
• server verifies signature using your public key

If signature matches:

Get Jaswinder Kumar’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

Access granted.

Where Does the Public Key Live?

On the server:

~/.ssh/authorized_keys

That file contains approved public keys.

Example:

ssh-rsa AAAAB3Nza...

If your matching public key exists there:

you get access.

If not:

Permission denied (publickey)

That familiar frustration.

Step 5: Secure Session Starts

Once authenticated:

the encrypted SSH tunnel becomes interactive.

Now:

Your Laptop <==== Encrypted SSH Session ====> Server

Everything flows through this tunnel:

• shell commands
• command output
• file transfers
• SCP
• SFTP
• port forwarding

This is why SSH is so powerful.

It’s not just login.

It’s a secure transport protocol.

Why SSH Became the Default

Because it solves real problems elegantly.

SSH gives:

✅ encrypted communication
✅ strong cryptographic authentication
✅ remote shell access
✅ file transfer
✅ tunneling support

For decades, this was revolutionary.

And still useful.

But SSH Assumes an Older Infrastructure Model

Here’s the hidden assumption:

The server must accept inbound connections.

That means opening the infrastructure.

Example:

Internet
   ↓
Port 22 Open
   ↓
Your Server

Now think at scale.

100 servers.

500 engineers.

Multiple environments.

Suddenly questions appear:

• Who has private keys?
• Were keys rotated?
• Did ex-employees keep copies?
• Is port 22 exposed publicly?
• Are bastion hosts secure?
• Are sessions logged?

SSH works beautifully.

But operationally, it creates management overhead.

Mental Model

Traditional SSH is:

direct human-to-server access using cryptographic key authentication over an encrypted tunnel.

Simple. Powerful.

But built for a world where servers were expected to be directly reachable.

And that’s exactly what AWS SSM challenges.

#aws #devops #cloudcomputing #cloudsecurity #ssh #ec2 #systemsmanager #iam #backend #architecture