I still remember the first time I broke SSH on a fresh Ubuntu box.

I changed a couple of lines in sshd_config, hit restart, and boom: weird error dump, prompt froze, and I had to reconnect. The server was new, so I thought, “What did I already mess up?”

If you’re seeing odd output when restarting SSH, your prompt locks up, or you get Connection refused after editing SSH settings, this is for you.

This guide focuses on a typical Ubuntu-style setup like Ubuntu 14.04 on a fresh server, but the basic troubleshooting steps are useful anywhere.

Who This Affects and What’s Going Wrong

You’re likely in one of these situations:

• Fresh Ubuntu server (like 14.04) just set up.
• You edited /etc/ssh/sshd_config (maybe changed the port, disabled root login, etc.).

• You restarted SSH and got a bunch of confusing output like:

• ... Error: (Re-)Registration failed: no registrar available

• Then your shell prompt becomes locked or unresponsive.
• Or a second terminal trying to log in gets Connection refused.

The good news: this usually means SSH config syntax or logic problem, not a totally broken server.

We’ll go step by step:

1. Keep or regain access safely.
2. Test your SSH config before restarting.
3. Fix config errors.
4. Restart SSH cleanly.
5. Avoid locking yourself out next time.

Step 1 – Don’t Close Your Working Session Yet

If you still have one shell session logged in, do not close it.

Even if the prompt looks odd or seems stuck for a moment after restarting SSH, wait a bit.

• If the current shell is frozen hard, open another SSH session in a new terminal window/tab and test login.
• If the new session also fails with Connection refused, keep that original session open as long as it responds to commands.

Why: if you completely lose all SSH access and your config is broken, you’ll need provider console access (like DO’s console) to recover.

Step 2 – Use sshd -T to Test Config Before Restart

The most useful single command from the source is this one:

sshd -T

Run that before restarting the SSH service whenever you change /etc/ssh/sshd_config.

This command:

• Loads your SSH daemon configuration.
• Tells you if there is an issue in a config file.
• Shows you which file and on what line the problem is.

Typical usage flow:

1. Edit config:
   bash
sudo nano /etc/ssh/sshd_config

2. Save the file.

3. Test config without restarting:
   bash
sudo sshd -T

4. If it prints an error, fix the line it complains about, then test again.

Only when sshd -T runs without error should you restart SSH.

Step 3 – Fix Typos and Obvious Config Mistakes

Most “Connection refused” or weird restart behavior after SSH edits come from tiny mistakes in sshd_config.

Some things to watch for (in the spirit of what’s hinted in the source):

• Typos in directives (for example, PermitRootLogn instead of PermitRootLogin).
• Missing yes/no or values for options.
• Invalid port values.

Since the source specifically mentions a typo in the config as a cause of Connection refused, we focus on that pattern.

Example workflow:

1. Open the config:
   bash
sudo nano /etc/ssh/sshd_config

2. Go to the line number reported by sshd -T (or by its error output).

3. Fix the typo or invalid value.

4. Save and exit, then re-run:
   bash
sudo sshd -T

5. Only after it passes, restart:
   bash
sudo service ssh restart

If your shell locked up exactly when restarting SSH, it’s usually safer to:

• Test with sshd -T in another window.
• Confirm it’s happy.
• Then restart SSH.

Step 4 – Recover When You Already Locked Yourself Out

Sometimes we don’t test first. We just restart, and then… nothing.

If:

• Your current SSH session died.
• New SSH connections get Connection refused.

You’ll need console access from your hosting provider.

The source hints at this with “you can use DO’s console access to log in and fix any issues.”

The general idea:

1. Log into your provider’s control panel.
2. Open their browser-based console or direct console for the VM.
3. Log in with the same user (often root or your created sudo user).
4. Edit /etc/ssh/sshd_config and undo your last changes, or just fix the reported typo.

5. Run:
   bash
sshd -T
   Make sure it doesn’t complain.

6. Restart SSH from the console:
   bash
service ssh restart

Once that works, try logging in via SSH again from your local machine.

Console access is your safety net when SSH is broken.

Step 5 – Dealing With Port 22 and SFTP Tutorials

The source also mentions this situation:

I have followed this tutorial and it is all working, but now I have followed the sftp tutorial too and it keeps checking port 22.

That usually means:

• Your SFTP client or another service/tutorial assumes SSH is still on port 22.
• But your current setup expects a different behavior or different port.

When you mix an “SSH hardening” tutorial and an “SFTP” tutorial, they can disagree on the port or how to connect.

Practical approach when something “keeps checking port 22”:

1. Confirm what port SSH is actually listening on in your config.
2. Make sure whatever SFTP config or client you’re using points to the same port.
3. If you changed the SSH port in one tutorial, update your SFTP config accordingly.

If things suddenly stop working right after following the SFTP tutorial, go back to your SSH config and test:

sshd -T

Fix any issues it reports, then restart SSH only after it passes.

Step 6 – Safer Workflow for Future SSH Changes

To avoid this drama every time you tweak SSH, use a safe pattern.

Here’s a simple routine you can follow so you don’t end up staring at a frozen prompt again:

1. Stay logged in in one terminal.

2. Open a second terminal for testing.

3. Edit SSH config in small steps.

4. Change just one or two settings at a time.

5. Always run:
   bash
sudo sshd -T
   before restarting.

6. Only then restart SSH:
   bash
sudo service ssh restart

7. Test a new login from the second terminal.

If something goes wrong:

• Don’t close the working shell until you fix it.
• Use console access if you lose everything.

This might feel slow at first, but it saves you from a lot of stress—especially on a production server.

Quick Recap

• Weird error spam and a locked shell after ssh restart usually point to a bad SSH config.
• Before restarting, always run sshd -T to catch typos and invalid settings.
• If SSH is already broken, use your provider’s console access to log in and fix /etc/ssh/sshd_config.
• When mixing SSH and SFTP tutorials, make sure they agree on ports and settings.
• Change SSH in small steps and keep one working session open until the new settings are confirmed.

Need more help? Check the latest CrushEdge posts.