A password is a secret you type. An SSH key is a secret you never send. That gap is the whole reason key-based login beats passwords, and Day 7 was where I set it up properly instead of halfway.
One Linux task, one AWS task. Configure passwordless SSH with a key pair, and change the type of an existing EC2 instance. Both are routine. Both have one detail that turns routine into broken if you skip it. The tasks come from the KodeKloud Engineer platform, the same as the rest of this series.
SSH keys: log in without ever sending a secret
Key-based SSH uses a pair. A private key that stays on your machine and never leaves it, and a public key you can hand out freely. The server keeps the public key, and when you connect, the two sides prove they match without the private key ever crossing the wire. A password does the opposite, it gets sent to the server on every login, which is one more thing that can be captured, guessed, or brute-forced.
Start by generating the pair on your own machine:
# Generate a key pair (modern OpenSSH defaults to ed25519)
ssh-keygen -t ed25519
A bare ssh-keygen works too. On current OpenSSH, it now defaults to ed25519, a fast modern key type, though older setups defaulted to RSA. I name the type with -t ed25519 so there is no guessing about what I ended up with. Accept the default file location, and add a passphrase if you want a second layer of protection on the key itself. Then push the public half to the server:
# Copy the PUBLIC key to the target server
ssh-copy-id user@hostname
ssh-copy-id handles the fiddly part for you. It appends your public key to ~/.ssh/authorized_keys on the server and sets the permissions correctly, which SSH is famously strict about. Do this by hand, and one wrong permission bit will make the server silently ignore your key while you wonder why it keeps asking for a password. Now test it:
# Should log you straight in, no password prompt
ssh user@hostname
Here is the part the task hints at but most people skip. Setting up a key does not disable passwords. Until you actually turn password login off, the server still accepts the weaker method, and anything on the internet can keep hammering it with guesses. Finish the job on the server side:
# In /etc/ssh/sshd_config, set:
PasswordAuthentication no
# Then reload the SSH daemon
sudo systemctl reload sshd
One warning that has locked plenty of people out of their own servers. Confirm your key login works in a second terminal before you disable passwords. If the key is not actually working and you switch passwords off, you have just removed your only way back in.
Resizing EC2: stop, modify, start, and mind the IP
The AWS task was to change an instance's type, say from a small t2.micro to a heavier t3.medium. You cannot do it live. The instance has to be stopped first because the type is tied to the physical host it runs on, and changing it means the instance gets placed somewhere new. Start by grabbing the ID:
# Get the instance ID by its Name tag
INSTANCE_ID=$(aws ec2 describe-instances \
--filters "Name=tag:Name,Values=my-instance" \
--query "Reservations[*].Instances[*].InstanceId" \
--output text)
Storing the ID in a variable keeps the next few commands clean and stops you from pasting the wrong i-0abc123 halfway through. Then stop it and wait for the stop to finish:
# Stop it, then block until it is fully stopped
aws ec2 stop-instances --instance-ids $INSTANCE_ID
aws ec2 wait instance-stopped --instance-ids $INSTANCE_ID
That wait line is underrated. Instead of running describe-instances over and over to check whether it stopped yet, the waiter blocks until the state is actually stopped, then hands control back to your script. It is the difference between automation that works and automation that races ahead and fails on the next line. Now change the type:
# Change the instance type while it is stopped
aws ec2 modify-instance-attribute \
--instance-id $INSTANCE_ID \
--instance-type '{"Value": "t3.medium"}'
The target type has to be compatible with the AMI's architecture. Moving between two x86 types, like t2 to t3, is fine. Jumping to a Graviton (ARM) type would need an image built for that architecture, so those are not interchangeable. Start it back up and confirm the change:
# Start it again and verify the new type
aws ec2 start-instances --instance-ids $INSTANCE_ID
aws ec2 describe-instances \
--instance-ids $INSTANCE_ID \
--query "Reservations[*].Instances[*].InstanceType"
Now, the detail that catches people. A stop and start is not a reboot. When you stop an instance and start it again, it usually comes back on a different public IPv4 address, because the old one gets released back into the pool. The private IP inside the VPC stays the same, but any SSH session, DNS record, or firewall rule pinned to the old public IP is now pointing at nothing. If you need a public address that survives a stop and start, that is exactly the problem an Elastic IP solves.
One more worth knowing. If the instance had any instance-store (ephemeral) volumes, stopping it wipes that data. EBS root volumes are safe, which covers most default setups, but check before you stop something that keeps scratch data on local disk.
The actual lesson
Both tasks look finished the moment the command returns success. They are not. SSH is not hardened until passwords are switched off. A resize is not safe until you have accounted for the public IP that just changed underneath you. The command completing and the job being done are two separate moments, and the gap between them is where real operations actually live.
So here is Day 7's question. Would you rather run the command and trust that success means safe, or know exactly what changed the second it returns, so nothing surprises you a week later?
Day 7 down. Ninety-three to go.