{"slug": "do-you-access-a-server-with-username-and-password-it-s-a-combination-padlock-the", "title": "Do you access a server with username and password? It's a combination padlock facing the street", "summary": "A developer recounts how a server break-in taught them the importance of disabling SSH password login in favor of SSH key pairs. The engineer, who transitioned from law to systems administration, explains that password-based SSH is like a combination padlock facing the street, vulnerable to brute-force attacks. Using SSH keys eliminates the risk of password leaks and speeds up access.", "body_md": "✍️ This post was written with two hands.The story — the first part — is Murilo's, lived and told by the person who was there. Thetechnical manual, at the end, was written with AI. The split is intentional and marked in the text. Nothing hidden about the seam: part is human, part is machine, and the reader sees both.\n\nIf you've ever managed or logged into a web server and never set up SSH keys, it's because you don't yet know the real risks of a break-in — and that's okay. Until you find out what can happen.\n\nLogging into a server over SSH with a username and password is like locking the front door of a house that faces the street, with nobody keeping watch. Anyone can try as many combinations as they want, freely.\n\nAnd setting this up takes almost as much time as typing a username and password — and it makes getting into the server much faster and easier afterwards.\n\nIgnorant of best practices, I managed my servers for a long time by typing:\n\n```\nssh user@server-ip\npassword\n```\n\nThat nearly cost me dearly, the day I found out my server had been broken into.\n\nAfter that incident, I realized just how vulnerable a username and password are on SSH.\n\nToday I can't say I sleep soundly — no system is completely break-in proof — but I sleep a lot better (and honestly, I always slept well, until I started managing servers).\n\nWaking up on a fine Sunday morning to do some maintenance on the server, and finding out it was broken into through the front door because you left a combination padlock facing the street — that is not the kind of surprise I'd wish on anyone.\n\nI have a degree in Law. I worked for 15 years in the legal field at a public institution, until I decided to venture into the world of programming.\n\nAnd where did I end up? Managing systems at the institution I work for, after spending some time building automations in Python.\n\nManaging systems wasn't exactly what I had in mind when I wanted to learn to code and understand the world of programming.\n\nBut that opportunity ended up teaching me far more about systems in general, about how the internet works — much more than I imagined back when the urge to work in development first hit me.\n\nToday I can't picture myself doing anything other than this: automating deploys and backups, improving application performance on the server side, monitoring, alerting.\n\nWhen it comes to SSH, there are bots scanning the internet all day long, trying usernames and passwords on the default port of servers all over the world. A weak, obvious, or reused password falls fast — it's just a matter of the right bot knocking on your door.\n\nA truly strong password holds up much longer: since every attempt has to travel back and forth across the network, brute-forcing it takes far too long to be worth it. But it's still a secret — and any secret can leak, be reused on a service that got compromised, or end up in the wrong place. That kind of slip doesn't usually happen to a good systems administrator. Which, at the time, I was not.\n\nSo one way to minimize the risk is to disable password login and allow access only through SSH keys.\n\nEven if you use a tool to fend off repeated attempts, like fail2ban, it's still less effective and less secure than SSH keys, because an attacker can switch IPs or use other tricks to get around it.\n\nWith an SSH key pair, the attacker only gets in if they get hold of the key. And for that, your slip-up has to be a bigger one — leaving it exposed somehow, or sharing it with the wrong people.\n\nWhen you set up the key pair, you put the padlock on the door and keep the key on your computer — so access happens only with the private key. And you can put that padlock on as many servers as you want.\n\nIn other words: you create a pair of keys, one private and one public.\n\nThe private one is the key; the public one is the padlock.\n\nSo you hold on to the key and place as many padlocks as you like on the servers you manage.\n\nFirst benefit: security.\n\nOn top of that, you can set up an alias. Instead of typing `ssh name@server-ip`\n\nand then the password every single time you want to reach the server, you just type `ssh alias`\n\n. It will ask for the passphrase you configured — only on the first access.\n\nFor the next ones that use that key — even on other servers — it's just `ssh alias`\n\n.\n\nWith that, you get both more security and more speed when accessing your servers.\n\nA padlock with a key is harder for an intruder to open than a combination padlock — wouldn't you agree?\n\nLuckily, when my server was broken into, it was a test machine I had just wiped to install a few applications for testing — I hadn't configured anything yet, nor deployed a single app. Damage contained, but the scare was real.\n\nWant to know how to set up SSH keys in practice? Below is a tutorial put together with the help of AI, and at the end a checklist and a command map — for both your PC and the server — to configure SSH keys, with a full, step-by-step explanation.\n\nIf you have any questions, I'm happy to chat. I love talking about technology, infrastructure, DevOps, SRE, and related topics.\n\n🤖 From here on: technical manual, written with AI.I told my story. Now comes the practical step-by-step — the part AI writes well. If you manage any server (a $5 VPS, an EC2 instance, the company machine), you can do this today, in about 20 minutes.\n\nThis is the hands-on part. I won't just list commands — I'll explain the *why* behind each one, because understanding the reason is what lets you touch a production server without breaking into a cold sweat.\n\nYou already saw the idea in the story above: the public key is the padlock, the private key is the key. It's just worth understanding what happens at the moment of login.\n\nWhen you connect, the server sends a challenge that **only the holder of the private key can solve**. Your machine solves that challenge locally and sends back only the answer — the private key itself never travels across the network, not even during login.\n\nThat's where the difference from a password lives. A password is a secret that leaves your machine every time and *can be guessed*. The private key never leaves, and can't be guessed: an Ed25519 pair is such an astronomically large number that brute-forcing it stops being an option. You're not using a stronger password — you're switching to a mechanism where guessing simply doesn't exist.\n\nOn **your computer** (not on the server):\n\n```\nssh-keygen -t ed25519 -C \"your-user@laptop-2026\"\n```\n\n`-t ed25519`\n\n— the algorithm. Ed25519 is modern, fast, and secure. Forget the old RSA.`-C`\n\n— a comment that stays attached to the public key. Use something that identifies the `your-user@laptop-2026`\n\n). Later on, this tells you which key is which.`~/.ssh/id_ed25519`\n\n).This creates two files:\n\n| File | What it is | Safe to share? |\n|---|---|---|\n`~/.ssh/id_ed25519` |\nPrivate key | Never. |\n`~/.ssh/id_ed25519.pub` |\nPublic key | Yes, freely. |\n\nThe private key must be readable only by you. Check, and fix it if needed:\n\n```\nls -la ~/.ssh/id_ed25519     # should show permission -rw------- (600)\nchmod 600 ~/.ssh/id_ed25519\nssh-copy-id user@server-ip\n```\n\nThis command asks for the **server password** — and that is, literally, the last time you'll type it. It copies your public key into the server's `~/.ssh/authorized_keys`\n\nfile, which is the list of padlocks that server accepts.\n\nTest it:\n\n```\nssh user@server-ip\n```\n\nAn important detail to confirm it worked: if it asks for a **passphrase**, you're good — that's the passphrase *for your key*. If it asks for a **password**, you're still using the server's password. These are different things; pay attention to which word shows up.\n\nMemorizing IPs is a waste of headspace. Create the `~/.ssh/config`\n\nfile on your computer:\n\n```\nHost app-prod\n    HostName 203.0.113.10\n    User deploy\n\nHost app-staging\n    HostName 203.0.113.20\n    User deploy\n\n# Applies to every host above\nHost *\n    IdentityFile ~/.ssh/id_ed25519\n    AddKeysToAgent yes\n    ServerAliveInterval 60\n```\n\n(The aliases and IPs above are fictional — replace them with your own.)\n\nFix the permission (`chmod 600 ~/.ssh/config`\n\n) and that's it — now you connect like this:\n\n```\nssh app-prod        # instead of ssh deploy@203.0.113.10\n```\n\n`ServerAliveInterval 60`\n\nsends a little signal every 60s so your connection doesn't drop on its own when you go a while without typing.\n\nWorking with a key isn't enough — as long as the password is still accepted, brute-forcing is still possible. The final step is to **disable password authentication**.\n\n⚠️ The golden rule: don't lock yourself out.Keep your current SSH session open throughout this whole step.You'll test the new configuration in asecondterminal window, without closing the first. If something goes wrong, the old session is still there for you to undo it. Only close it once the test passes.\n\nConnected to the server, edit the SSH daemon configuration:\n\n```\nsudo nano /etc/ssh/sshd_config\n```\n\nMake sure these four lines look like this (uncomment any that have a `#`\n\nin front):\n\n```\nPermitRootLogin no\nPasswordAuthentication no\nPubkeyAuthentication yes\nKbdInteractiveAuthentication no\n```\n\n`PermitRootLogin no`\n\n— no one logs in directly as `root`\n\n. You log in as a regular user and use `sudo`\n\nwhen needed.`PasswordAuthentication no`\n\n— the heart of the change: passwords are no longer accepted.Before applying it, **validate the syntax** — a typo here can take SSH down:\n\n```\nsudo sshd -t\n```\n\nIf it prints nothing, you're clean. Then restart the service:\n\n```\nsudo systemctl restart ssh\n```\n\n📝 IfOn some distributions the service is called`ssh`\n\nisn't the service name.`sshd`\n\n. If the command above complains, use`sudo systemctl restart sshd`\n\n.\n\nNow the test — **without closing the current session**. Open a new terminal:\n\n```\nssh app-prod\n```\n\nGot in with the key? Great. Now confirm the password is really dead:\n\n```\nssh -o PubkeyAuthentication=no user@server-ip\n```\n\nThis command tells SSH to ignore the key on purpose. The expected result is `Permission denied`\n\n. If you got a \"Permission denied\", **congratulations — the password door is shut.** Now you can finally close the old session.\n\nYour private key is your identity on those servers. Lose the file = lose access. Leak the file = hand access to someone else. Treat it accordingly.\n\n**Do:** save the key's contents in a **secure note inside a password manager** (Bitwarden has a free plan and works well). Copy the contents with `cat ~/.ssh/id_ed25519`\n\nand paste them into a Secure Note. Keep the passphrase in a *separate* place.\n\n**Don't:** save the key on Google Drive, Dropbox, or OneDrive. Those services sync the file automatically across several devices and expose it through the browser. You lose control over where your identity lives.\n\nOptional, but recommended on servers exposed to the internet:\n\n`Port XXXX`\n\nto `sshd_config`\n\nand the matching `Port XXXX`\n\nin the host block of your `~/.ssh/config`\n\n.`fail2ban`\n\n.`~/.ssh/config`\n\nset up with aliases`PasswordAuthentication no`\n\nand `PermitRootLogin no`\n\non all of them`Permission denied`\n\non the test)`fail2ban`\n\non public serversEvery command that appeared above, and what it does:\n\n`ssh-keygen -t ed25519 -C \"comment\"`\n\n— generates the key pair (private + public) using the Ed25519 algorithm.`ssh-keygen -p -f ~/.ssh/id_ed25519`\n\n— adds or changes the passphrase of an existing key, without changing the key itself.`ls -la ~/.ssh/id_ed25519`\n\n— shows the key file and its current permission.`chmod 600 ~/.ssh/id_ed25519`\n\n— restricts read/write of the private key to your user only.`chmod 600 ~/.ssh/config`\n\n— does the same for the aliases file.`ssh-copy-id user@server`\n\n— copies your public key into the server's `authorized_keys`\n\n.`ssh app-prod`\n\n(or `ssh user@ip`\n\n) — connects to the server.`sudo nano /etc/ssh/sshd_config`\n\n— opens the server's SSH daemon configuration for editing.`sudo sshd -t`\n\n— validates the `sshd_config`\n\nsyntax before applying it (prints nothing if it's OK).`sudo systemctl restart ssh`\n\n— restarts the SSH service to apply the new configuration (`sshd`\n\non some distros).`ssh -o PubkeyAuthentication=no user@ip`\n\n— forces password login on purpose; used to confirm the password is blocked (should give `Permission denied`\n\n).`cat ~/.ssh/id_ed25519`\n\n— prints the private key's contents, to copy into your password manager.*Murilo Negrão — backend/DevOps developer. I write about modernizing legacy stacks and the bridge between code and infrastructure.*", "url": "https://wpnews.pro/news/do-you-access-a-server-with-username-and-password-it-s-a-combination-padlock-the", "canonical_source": "https://dev.to/murilo_negrao_59aada6e774/do-you-access-a-server-with-username-and-password-its-a-combination-padlock-facing-the-street-cn3", "published_at": "2026-07-17 12:50:07+00:00", "updated_at": "2026-07-17 13:01:35.017125+00:00", "lang": "en", "topics": ["developer-tools", "ai-tools"], "entities": ["Murilo", "Python", "fail2ban"], "alternates": {"html": "https://wpnews.pro/news/do-you-access-a-server-with-username-and-password-it-s-a-combination-padlock-the", "markdown": "https://wpnews.pro/news/do-you-access-a-server-with-username-and-password-it-s-a-combination-padlock-the.md", "text": "https://wpnews.pro/news/do-you-access-a-server-with-username-and-password-it-s-a-combination-padlock-the.txt", "jsonld": "https://wpnews.pro/news/do-you-access-a-server-with-username-and-password-it-s-a-combination-padlock-the.jsonld"}}