← all posts

SSH, TLS, And AWS SigV4 Authentication

June 20, 2024
SSH, TLS, And AWS SigV4 Authentication

SSH, TLS, and AWS SigV4 are often discussed together because they all involve keys and signatures. They solve different problems.

The clean mental stack is:

  1. TCP gives you transport.
  2. TLS protects the channel.
  3. SSH protects an interactive management session.
  4. SigV4 proves who signed an AWS API request.

People get into trouble when they treat them as interchangeable security layers. They are not.

SSH Public Key Authentication

SSH public key authentication uses asymmetric cryptography.

You keep the private key locally. The server stores your public key in authorized_keys. During authentication, the server sends a challenge, the client signs it with the private key, and the server verifies it with the public key.

The server never needs your private key. That is the main security benefit.

Operationally, SSH is about controlled access to a machine or shell-like session. It is session-oriented identity.

TLS

TLS starts with asymmetric cryptography to authenticate the server and negotiate a shared secret. After the handshake, the session uses symmetric encryption because it is faster.

For most web traffic, TLS answers: am I talking to the real server, and is the channel encrypted?

That is why HTTPS plus valid certificates solves a different problem from AWS API signing. TLS secures the pipe. It does not tell AWS which IAM principal intended a specific request.

AWS SigV4

SigV4 is different. It does not encrypt the request by itself. HTTPS handles encryption. SigV4 proves who made the request and whether the request was changed.

The client uses an AWS secret access key to calculate an HMAC signature over the request. AWS uses the same secret key stored in IAM backend systems to recompute the signature. If the signatures match, the request identity is valid.

This is symmetric signing. It is fast enough for high-volume API traffic, but the secret key must be protected like a password.

That is why long-lived access keys are operationally dangerous. They are not just credentials. They are reusable signing material.

Stateless Request Signing

SigV4 is stateless. Every request carries enough information to verify identity:

  1. Access key.
  2. Timestamp.
  3. Signed headers.
  4. Request hash.
  5. Signature.

The timestamp also limits replay risk. A stolen old request should not remain valid forever.

Best Practice

Avoid long-lived access keys where possible. Use IAM roles and STS temporary credentials. Temporary credentials include an access key, secret key, and session token, and expire automatically.

For API Gateway with AWS_IAM authorization, three things are required:

  1. The method uses AWS_IAM authorization.
  2. The caller has execute-api:Invoke.
  3. The caller signs the request with SigV4.

Plain curl is anonymous. Use an SDK, awscurl, or a tool that supports AWS signing.

This shows up often with API Gateway AWS_IAM authorization: HTTPS alone is not enough. The caller also needs a correctly signed request and IAM permission to invoke the method.

The Mental Model

SSH proves a person or machine owns a private key for a session. TLS protects a channel. SigV4 proves each AWS API request was signed by a caller with valid credentials. Mixing these up leads to bad security design.

;