« All posts

100 Days of DevOps: Killing SSH Passwords and Resizing EC2

Day 7 of a 100-day DevOps series covers setting up passwordless SSH properly and the public IP pitfall that trips people up when resizing an EC2 instance.

This entry covers Day 7 of a 100-day DevOps series built on the KodeKloud Engineer platform. The first task replaces password-based SSH login with key-based authentication. After generating a key pair with ssh-keygen and pushing it to the server via ssh-copy-id, the step most people skip is actually disabling password authentication in sshd_config and reloading the daemon — until that's done, the server still accepts weaker password logins and remains open to brute-force attempts. The author stresses verifying key-based login in a second terminal before disabling passwords, since failing to do so can lock you out of your own server.

The second task is resizing an EC2 instance type (e.g., from t2.micro to t3.medium). This can't be done while running, since the instance type is tied to its underlying physical host, so it must be stopped first. Using the AWS CLI, the instance ID is fetched, then stop-instances and wait instance-stopped ensure the stop completes before modify-instance-attribute changes the type. The target type must match the AMI's architecture — switching between x86 types works fine, but moving to ARM-based Graviton instances requires a compatible image.

The key detail highlighted is that stopping and starting an instance is not the same as rebooting it. The instance typically receives a new public IPv4 address on restart, breaking any SSH sessions, DNS records, or firewall rules tied to the old IP — a problem an Elastic IP solves if a persistent address is needed. Instance-store volumes are also wiped on stop, while EBS root volumes remain intact. The broader lesson: a command succeeding isn't the same as the task being safely done, and that gap is where real operational risk lives.

» SourceDev.to