How to fix my problem with SSH on Raspberry Pi?

You type the command, hit enter, and wait. Nothing. Just an error. You try again, double-check the IP, glance at the router lights, feel that slow rise of frustration. SSH isn’t working—and you have no idea why.

This isn’t rare. Whether you're setting up a single Pi in your garage or shipping out batches of branded kits like we do at MaidaTech, SSH troubles sneak up on you when you least expect it. They interrupt your flow, block your delivery timeline, or worst of all—make you look unreliable to your customers.

I’ve been through all of it. That dead silence on the terminal. The “Connection refused” message that feels more personal than it should. And over time, I’ve learned it’s rarely a big issue. It’s always one of a dozen small things—each easy to fix if you know what to check, and in what order.

So this guide isn’t just a list of commands. It’s a working toolkit for rebranders, makers, or anyone like my clients Davide or Jacky—people who need answers fast, clear, and practical. Let’s fix your SSH problem together. Step by step.

1. Why am I unable to connect via SSH to my Raspberry Pi?

Before we jump into fixes, let’s pause and think: why are we stuck here? At each point I’ll ask the “what if” question, dig a little deeper, and try to walk in your shoes — because I’ve been there.

1.1 Is SSH even enabled on the Raspberry Pi?

Often the answer is simple: no. The SSH server may not be listening. According to official docs, SSH on Raspberry Pi OS is disabled by default.
I remember one night I flashed a fresh OS for a client’s batch of custom cases and assumed SSH was live… big mistake. I wasted half an hour staring at “timeout” before realising this.
If SSH isn’t enabled, it doesn’t matter how perfect your network is — you’re blocked at the door.

1.2 Is the Raspberry Pi online and reachable on the network?

Next: the board might be on, but maybe it’s invisible on the network. The docs show we must know the Pi’s IP address and that the client machine is on the same network.
Imagine I shipped a kit to a distributor in Europe, told them “just SSH in”, and they replied: “I can ping it but no login”. Turned out the Pi got a link‑local address (169.254.x.x) because WiFi credentials were wrong.\
So: is the Pi powered? Connected via Ethernet or WiFi? Does it have a valid IP in the same subnet as your client?

1.3 Am I using the correct username, password, IP address and port?

Simple but overlooked. Default user is often “pi”, password “raspberry” (though default password auth may be disabled or warned against).
I once had a customer send me frantic messages: “It says access denied – I changed nothing!” After 10 minutes I asked: “Are you using pi\@192.168.0.14 port 22?” They replied: “Oh I changed port to 2222 and forgot.”
Make sure you’re pointing to the right IP, the right port, the right user. And if key‑based auth is used, ensure you’re referencing the right key.

1.4 Are there firewall rules, router restrictions or network segmentation blocking SSH?

Here’s where things get tricky. Even when everything above is correct, network policies can block SSH. Maybe your client machine is on a guest WiFi, or your router blocks inbound port 22, or you’re behind VPN or corporate firewall.\
In one OEM project I handled, the reseller was using WiFi with client isolation — the Pi was connected but isolated from other devices. So while it looked “online,” SSH simply couldn’t reach it.\
So ask: is there any segmentation? Is port 22 open? If remote over internet, is port‑forwarding configured properly?

As you finish this section, you might realise one of these four is your culprit. If yes — great. If not — let’s go deeper into how to enable and diagnose until we fix it.

2. How to enable SSH correctly on the Raspberry Pi

Now that we’ve asked “why”, let’s act: enable SSH properly. I will share multiple methods because your setup might differ — headless, desktop, custom image. And I’ll point out where things go wrong (so you can avoid my mistakes).

2.1 Enabling SSH via the GUI (if using desktop)

If your Pi has a screen & keyboard, this is easiest. Go to Preferences → Raspberry Pi Configuration → Interfaces → Enable SSH. The official guide mentions this path.
But here’s the catch: many users skip this because they image and send headless. So if you did skip, don’t assume this was done.

2.2 Enabling SSH via the terminal or raspi‑config tool

In a terminal type:

sudo raspi-config  

Then go to Interfacing Options → SSH → Yes. Then reboot or start the service. Many threads confirm this step.
Bonus tip: after enabling, run:

sudo systemctl enable ssh  
sudo systemctl start ssh  
sudo systemctl status ssh  

to check it’s actually running.

2.3 Enabling SSH in headless mode (creating the ssh file in /boot)

This is critical if you don’t have monitor/keyboard for the Pi. On the SD card’s boot partition, create an empty file named ssh (no extension). On next boot, the OS enables SSH and deletes the file.
I once built dozens of units for a reel of kits — used this method every time. If you forget this, you’ll curse at your router trying to ping and connect.

2.4 Verifying that the SSH service is running and listening

Even if you enabled SSH, you need to verify. On the Pi, run:

sudo netstat -tlnp | grep sshd  

or

sudo service ssh status  

If it’s not listening on port 22 (or your chosen port), you’re still stuck. One client of mine thought enabling was enough — but they had turned the service off by mistake in custom image build.\
This step filters out “I enabled it” claims vs “it is actually running”.

And with that, you’re set. Let’s move on to diagnosing actual error messages — once you connect and still hit a snag.

3. How to diagnose common SSH error messages

When you try to SSH and it fails, the error message is your friend. It tells you what kind of problem you have. I’ll walk you through the common ones I’ve seen, what they mean, and how to think of them critically.

3.1 “Connection refused” — what it usually means and how to fix

When you see “connection refused”, it almost always means: no SSH server listening at that IP/port.\
Possible causes:

• SSH service disabled or not started.

• Wrong IP address.

• Wrong port (if you changed it).\
  For example, I had a customer who changed SSH to port 2022 for security. They forgot that, so connection refused.\
  Fix checklist:

• Verify service running (sudo status ssh).

• Ensure correct IP + port.

• Verify firewall allows that port.

3.2 “Permission denied” or “Authentication failed” — troubleshooting credentials and keys

This error means you reached the server, but it refused your credentials.\
Possible causes:

• Wrong username/password.

• Password login disabled.

• Public key auth not set up correctly.\
  For instance, one OEM client used key‑only auth without putting the public key in ~/.ssh/authorized_keys. They wondered why “permission denied”.\
  Fix:

• Double‑check username.

• Try password first if enabled.

• If key‑auth: check key copied, permissions correct (~/.ssh = 700, authorized_keys = 600).

• If root login disabled (good practice) ensure you use the correct non‑root user.

3.3 “Connection timed out” or “No route to host” — network issues and IP address problems

This is where network layers bite. Either the Pi isn’t reachable or something in between blocks you.\
Possible causes:

• Pi is offline or has wrong IP.

• Client network different subnet.

• Router blocks or isolates devices.\
  In my early days shipping custom Raspberry Pi cases worldwide, I had a Belgian buyer complain: “I can’t reach it from my office network.” Turned out corporate firewall blocked outgoing port 22.\
  Fix:

• On client: ping <pi_ip>, traceroute <pi_ip>.

• On Pi: verify IP (hostname -I).

• Check router settings for isolation or guest WiFi.

• Check any VPN or firewall between client and Pi.

3.4 Checking logs (/var/log/auth.log) and the SSH daemon configuration (/etc/ssh/sshd_config)

If you’ve passed the obvious checks and still stuck, logs and config files reveal deeper issues.

• On Pi: sudo tail -f /var/log/auth.log while attempting login. This may show “Invalid user”, “Too many attempts”, etc.

• Inspect /etc/ssh/sshd_config: Did you allow password auth? Did you change port? Did you disable root login?\
  One of my customers modified their custom image’s sshd_config to only allow key auth, but forgot to install keys — they were locked out.\
  Fix: Backup the file, review the lines, revert to defaults if needed, then sudo systemctl restart ssh.

Having walked through these error types — you should now be able to identify what kind of SSH problem you're facing. But let’s go further: fixing authentication and network/config issues in detail.

4. How to fix SSH authentication issues

Let’s handle the authentication side of SSH. Because even when network is perfect, who is logging in, how, and with what permissions matters a lot. And I’ll bring my factory‑mindset in: when shipping custom cases or OEM kits, you want robust and predictable access.

4.1 Using password authentication: verifying user, password, account status

If you still use password login (fine for small setups, but less for remote or production), check:

• That the user exists (id username).

• That password is set and not expired.

• That PasswordAuthentication yes is set in sshd_config.\
  Here’s a table to show common faults:

In my factory I often generate a dedicated “factory” user for remote debug. If that login fails, I know password auth is broken or disabled.

4.2 Using public‑key authentication: generating keys, installing authorized_keys

Key auth is more secure and preferred for B2B hardware projects. Steps:

1. On client: ssh-keygen -t ed25519 (for example)

2. Copy ~/.ssh/id_ed25519.pub to Pi’s ~/.ssh/authorized_keys

3. Set permissions: chmod 700 ~/.ssh, chmod 600 ~/.ssh/authorized_keys

4. In sshd_config: ensure PubkeyAuthentication yes and optionally PasswordAuthentication no.\
   The official Raspberry Pi docs describe this.
   I recall a distributor who forgot step 2 but assumed key was installed — wasted hours. Don’t assume. Verify.

4.3 Disabling/shoring up weak defaults: changing default user/password, disabling root login

From a factory perspective, you’ll ship units with default credentials — but you should instruct clients to change them. The default “pi/raspberry” is known.
Actions:

• Run passwd to change password.

• In sshd_config, set PermitRootLogin no.

• Consider renaming or removing “pi” user.\
  This builds trust with your B2B customers (they care about security) and reduces support from you later.

4.4 Ensuring correct file permissions on .ssh directory and authorized_keys

This is a subtle one. Even if everything else is correct, wrong permissions will silently block login.\
Rules:

• ~/.ssh folder = 700 (drwx——)

• ~/.ssh/authorized_keys = 600 (-rw——)

• The home folder of the user shouldn’t be writable by others.\
  I once had a case where someone copied keys via USB and set full 777 permissions — root refused login due to “unsafe permissions”.\
  So check permissions, ownership (chown username:username ...), and retry.

With authentication squared away, we move on to network/config — because your Pi might be fine locally but failing when you move to remote or complex networks.

5. How to resolve network or configuration problems

Networks are messy. Routers, subnets, firewalls, NATs — they all add complexity. I’ve shipped kits globally, and network issues always sneak in. Let’s unpack the main ones.

5.1 Finding the correct IP address of the Raspberry Pi (hostname ‑I, router DHCP list)

You may think you know the IP, but it’s changed. On the Pi type:

hostname -I

or check router DHCP list. The official doc shows how to find it.
I had a client who used .local hostname and on Windows it resolved to the wrong Pi (they had two boards). They ended up SSHing into the other one — with weird results. Always verify.

5.2 Ensuring the client and Raspberry Pi are on the same network (or VPN)

If your client machine is on a different subnet (e.g. guest WiFi, VPN, corporate LAN), connectivity might fail. The Pi might respond to ping but not allow SSH.\
Simple test: from client, ping the Pi. If ping works but SSH doesn’t, suspect ports or firewall. If ping fails, you’re on the wrong network or Pi is offline.\
In one B2B case, a reseller had the Pi on 5GHz guest WiFi while their config laptop was on 2.4GHz main network — devices were isolated.

5.3 Dealing with router/firewall port forwarding for remote SSH (over internet)

If you connect over the internet (not local LAN), you’ll often need to forward port 22 (or whatever port you choose) on the router to the Pi’s internal IP.\
The official doc says: you can expose SSH, but you must consider security.
From a factory view: when you ship kits to clients abroad, I always ask “Is your router forwarding the port? Is your ISP blocking incoming connections on 22?”\
Tip: Change default port to something like 2022 to reduce random scans.

5.4 Changing the default SSH port and opening that port in firewall/iptables

Changing the port is a simple step but surprisingly effective. In sshd_config, set Port 2022, then restart ssh. On the router, forward new port to Pi. In iptables or ufw, allow the new port.\
Advantages: fewer brute‑force attempts, less chance of ISP/hosting filtering port 22.\
From my factory shipments: I advise my clients to change ports immediately when deploying custom boxes for customers.

Once you’ve walked network/config and authentication, you’re almost done. But for robust, production‑grade deployments (especially for custom kit customers), you should layer in advanced practices.

6. Advanced fixes and best practices

If you’re deploying many units (as my business does: custom Raspberry Pi cases, power supplies, kits for distributors), you’ll want more than “it works”. You’ll want secure, maintainable, automated. So let’s go there.

6.1 Using ssh -v or verbose mode to trace the SSH connection attempt

When things get frustrating, verbose mode helps: from client

ssh -v username@ip_address

You’ll see step‑by‑step what SSH is doing. Maybe key exchange fails, maybe host key mismatch. This is how you see what’s going wrong.\
I often use this when clients tell me “It worked yesterday, now it doesn’t.” The trace reveals changed IP, missing keys, etc.

6.2 Regenerating host keys / resetting sshd_config back to factory defaults

If the Pi has been cloned or re‑imaged many times, host keys might duplicate, or sshd_config is badly edited. You can regenerate keys:

sudo rm /etc/ssh/ssh_host_*  
sudo dpkg-reconfigure openssh-server  

And if configuration is a mess, restore the default sshd_config from backup or package.\
One incident: a client tried to disable root login and allow only key auth, but left wrong syntax — SSH failed completely. They had to pull the SD card, fix the file offline, then reboot.

6.3 Hardening SSH: disabling password auth, enabling key‑only, changing port, monitoring logs

From a B2B hardware/kit perspective, you’ll want clients to follow this. Best practices:

• PasswordAuthentication no (once key auth confirmed)

• PermitRootLogin no

• Use key‑only login.

• Change default port.

• Enable fail2ban or similar to ban repeated login attempts.

• Monitor /var/log/auth.log for suspicious access.\
  This reduces risk for your customer and reduces support overhead for you down the line.

6.4 Automating updates, monitoring, and ensuring the Raspberry Pi firmware/OS is up to date

Finally, to keep everything smooth:

• Enable automatic security updates (sudo apt update && sudo apt upgrade -y, or use unattended‑upgrades).

• Monitor device uptime and SSH health (e.g. ping from external server overnight).

• In production kits, include documentation for client: “Check SSH service, check port, check logs”.\
  I’ve found that when my customers follow this, they come back happier and with fewer support tickets.

Conclusion

I hope walking through these six major areas has given you both a roadmap and the mindset to solve SSH issues on your Raspberry Pi setups. We began with asking why you can’t connect, then moved to how to enable SSH, diagnosed common error messages, fixed authentication issues, handled network/config problems, and finally laid out the advanced practices that will help you deliver reliable devices — whether it’s a single board in your lab, or 1,000 units shipped to a distributor overseas. As someone who runs a factory supplying custom Raspberry Pi cases, power supplies and kits worldwide, I’ve seen that the smoothest shipping days happen when we get these foundational steps right. So next time SSH fails … take a breath, walk through this checklist, and find the fix. Your workflow — and your clients — will thank you.