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 [email protected] 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 [email protected]
# password: prompted, because password auth is enabled on the hostWhy 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 keyReachability 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.