SSH Typo Locked Me Out: How I Fixed My Linux Server

So there I was, feeling like a total Linux wizard. Fresh out of a bootcamp, I’d just spun up my very first DigitalOcean droplet. It was a tiny, cheap VPS, but to me, it was the keys to the kingdom. My mission? To deploy a simple static website. Simple, right? Famous last words. I’d read all about SSH, the secure way to connect to your server. I knew the drill: ssh username@your_server_ip. Easy peasy. Except, it wasn't.

TL;DR: I accidentally edited the SSH server configuration file on my Linux VPS to disallow all root logins and then removed my user's SSH access. A simple typo in sshd_config locked me out. I managed to regain access by using the DigitalOcean console and fixing the configuration file, then re-adding my user to the sudoers file.

The "Oops Moment": A Typo and a Click

I was logged into my brand new server as root (yeah, I know, rookie mistake #1, but we'll get to that). I decided to harden the security a bit. I remembered reading that it's bad practice to allow direct root logins over SSH. So, I decided to edit the SSH daemon configuration file, sshd_config. I opened it up with nano /etc/ssh/sshd_config.

My goal was to change PermitRootLogin yes to PermitRootLogin no. Seems straightforward. I found the line, typed no, saved the file, and then, to make sure my changes took effect, I decided to restart the SSH service. The command for that is usually something like systemctl restart sshd.

I hit enter. No immediate errors popped up. "Great!" I thought. "This is going swimmingly."

Then, I decided to test it. I opened a new terminal window, leaving my existing root session running. I typed:

ssh root@YOUR_SERVER_IP_ADDRESS

And I was greeted with:

ssh: connect to host YOUR_SERVER_IP_ADDRESS port 22: Connection refused

"Huh?" I thought. "Connection refused? That's weird." I double-checked the IP address. It was correct. I tried pinging the server. It responded. So, the server was online, and the IP was right. What was going on?

My heart started doing a little samba in my chest. I went back to my original terminal, the one still connected to the server. I tried restarting SSH again: systemctl restart sshd.

This time, I got a different error:

Failed to restart sshd.service: Unit sshd.service not found.

"Unit not found?!" My blood ran cold. The SSH service wasn't just not running; it was like it had vanished into thin air. Panic started to set in. I typed exit to close my existing session, just to see what would happen.

And then I tried connecting again.

ssh root@YOUR_SERVER_IP_ADDRESS

Result:

ssh: connect to host YOUR_SERVER_IP_ADDRESS port 22: Connection refused

It was official. I had well and truly locked myself out of my own server. My first act of "security hardening" had turned my shiny new VPS into a very expensive, very inaccessible brick.

The Digital Lifeline: Console Access to the Rescue

My initial thought was, "Oh no, I have to rebuild the whole thing!" But then I remembered the features of cloud providers. DigitalOcean, like most others, offers a console or "recovery" mode. This is basically a direct terminal access to your server's operating system, bypassing the network and SSH entirely. It’s like having a keyboard plugged directly into the motherboard.

I logged into my DigitalOcean dashboard, navigated to my droplet, and looked for the console option. There it was, usually under a "Console" or "Access" tab. Clicking it opened a new browser window with a terminal prompt. I was logged in as root!

Phew. The server was still running. Now, to figure out why I couldn't SSH.

First, I checked the status of the SSH service again:

systemctl status sshd.service

The output was pretty clear:

● sshd.service - OpenSSH server daemon
     Loaded: ...
     Active: inactive (dead)
       Docs: man:sshd(8)
             man:sshd_config(5)

It confirmed that sshd was indeed dead and not starting. I then remembered that critical change I made in sshd_config. The error message about Unit sshd.service not found was a red herring, likely caused by the SSH daemon crashing so hard it messed with systemd's ability to track it properly. The real problem was the configuration file.

I opened it again:

nano /etc/ssh/sshd_config

And there it was, my innocent typo:

PermitRootLogin no

I had changed it to no, which is good practice, but the real problem was that I hadn't yet created a non-root user and given it sudo privileges. So, by disabling root login, I effectively disabled all ways to log in, because I hadn't set up any alternatives! And worse, I think I might have also accidentally commented out or deleted a line related to password authentication or perhaps even the ListenAddress directive, hence the "Connection refused" earlier. The exact sequence of typos is a blur of panic.

The Fix: Rebuilding Access, One Line at a Time

My immediate goal was to get any SSH access back, preferably not as root.

    PermitRootLogin yes
    

    systemctl restart sshd.service
    

This time, it reported success:

    ● sshd.service - OpenSSH server daemon
         ...
         Active: active (running) ...
    

```bash