Local SSH vs EC2: Reachability and Auth

A common assumption is that a device on the local network connects over SSH without a key because it is local, while EC2 needs a .pem because it is remote. That is the wrong model. Being on the LAN and needing a key are unrelated. SSH always involves two separate concerns: how you reach the host, and how you prove who you are. This note separates the two so the LAN vs EC2 difference makes sense.

Two independent concerns

Every SSH connection answers two questions that do not depend on each other.

Concern	Question	Set by
Reachability	Can the network route me to the host on port 22?	Addressing, NAT, firewall / security group
Authentication	Can I prove I am allowed in?	The host sshd config: password, key, or both

A LAN connection and an EC2 connection differ on both axes, but for different reasons, so it is worth reading them apart.

Why the LAN case needs no key

On the local network the host sits behind the same router, reachable directly by its private IP with no NAT traversal or port forwarding. That covers reachability only.

Authentication is a separate choice. A typical desktop or laptop distro ships sshd with password login allowed, so ssh user@192.168.1.57 prompts for the user login password. It works without a key because the host allows passwords, not because the connection is local. Put your public key in the host authorized_keys and the same LAN connection becomes key based.

ssh user@192.168.1.57
# password: prompted, because password auth is enabled on the host

Why EC2 requires a .pem

EC2 is not stricter because it is remote. AWS provisions the instance with password login disabled and installs your public key through cloud-init at first boot. The key is mandatory by configuration, not by distance.

ssh -i ~/.ssh/my-key.pem ubuntu@my-ec2-public-ip
# key required, because AWS set PasswordAuthentication no and preinstalled the key

Reachability also differs here: EC2 has a public IP or DNS name, and the security group must allow inbound port 22 from your address. That is the addressing axis, still separate from auth.

The full picture

Laying both cases on the two axes shows the pattern. Neither the key requirement nor the addressing follows from local vs remote alone.

	Reachability	Authentication
LAN host	Private IP, direct on the same network	Password or key, whatever sshd allows
EC2	Public IP or DNS, security group must open 22	Key only, because AWS disabled passwords

The takeaways that follow from separating the axes:

• A key is required when the host sshd disables password login, on any network. Flip that setting and a LAN host can require a key too.
• Password login can work over the public internet if a host enables it, which is why it is usually disabled on exposed servers.
• Reachability is about routing and firewalls, never about which auth method you use.

See also

• Reach a local host by name over SSH
• SSH into a local network device
• SSH into EC2 from Linux host
• Adding a new SSH key to EC2