SSH keys instead of a password on the box
A private file you keep, a public file on the server, and why password SSH is still a gift to scanners.
SSH is how you log into a Unix box over the network without sending a password in the clear. The old way was a password on the account. The better way, for about twenty years now, is a key pair: a private file you keep, and a public file you paste onto the server.
How the two files work
You generate the pair on your own machine. The private key never leaves. The public key goes in `authorized_keys` on the server. When you connect, the server proves you hold the matching private key. Nobody types the account password into a café keyboard.
If someone steals the private key file and it has no passphrase, they are you. Put a passphrase on the key. Use the agent so you type it once in the morning, not on every hop.
Do not email the private key. Do not drop it in Slack. Do not copy it to a USB stick that lives in a laptop bag. Treat it like a house key that also opens the office.
Turn off the password door
Once keys work, disable password SSH on that server. Leave one emergency path you tested: a console in the cloud panel, or a second key on a second machine. If you lock yourself out with no console, that is a lesson, not a mystery.
Root login over SSH should be off. Log in as a user, then sudo. That is least privilege in one sentence, and it is how people have run Unix since the 90s.
Laptops and phones
A key on a laptop is fine. A key on a phone is possible and easy to lose. If you administer boxes from a phone, know where the key lives and how you would revoke it. On the server, deleting one line from `authorized_keys` is the revoke.
Passwords on SSH still exist for the same reason telnet configs still exist: someone never finished the job. Finish it. Keys, passphrase, no password login, no root login. Then the scans that hammer port 22 waste their time on a door that does not take a guess.