SSH Not Connecting? Here Are 8 Things to Check

with commands and fixes you can use right now

1. Is the SSH Service Running?

First things first: make sure the SSH daemon is even alive on the target server.

# On the remote server
sudo systemctl status ssh

or on some distros:

sudo systemctl status sshd

If it’s not running:

sudo systemctl start ssh
sudo systemctl enable ssh

If you’ve locked yourself out of a cloud VM, most providers (AWS, GCP, Azure) have a “serial console” or “emergency mode” that lets you restart SSH from outside.

2. Can You Even Reach the Host?

Sometimes it’s not SSH at all — the network is down. Test connectivity:

ping -c 4 server_ip

If ping is blocked but you still want to check the port directly:

nc -zv server_ip 22

This will tell you if port 22 is reachable.

3. Are You Using the Right Username?

This one sounds silly, but trust me: I’ve spent hours because I typed “root” instead of “ubuntu”.

Cloud providers often use specific default usernames:

• AWS EC2: “ec2-user” or “ubuntu”
• GCP: your Google account username
• Azure: the user you created when provisioning the VM

Double-check your provider docs or try:

ssh ubuntu@server_ip

4. Is the Key Correct?

If you see this error:

Permission denied (publickey).

…it usually means you’re using the wrong private key or it’s not authorized on the server.

Run with verbose mode:

ssh -v -i ~/.ssh/my_key.pem user@server_ip

Look for lines like:

Offering public key: /home/user/.ssh/my_key.pem

If the server rejects it, make sure your key is added to ~/.ssh/authorized_keys on the server.

5. Are the Permissions Correct?

SSH is picky about file permissions. The private key should be 600, and .ssh directories should be 700.

chmod 600 ~/.ssh/my_key.pem
chmod 700 ~/.ssh

On the server:

chmod 600 ~/.ssh/authorized_keys
chmod 700 ~/.ssh

If these are wrong, SSH will silently refuse to connect.

6. Did You Lock Yourself Out with “sshd_config”?

Misconfigurations in /etc/ssh/sshd_config can easily lock you out. Some common mistakes:

• Disabled password login before adding a key.
• Setting PermitRootLogin no and then trying to SSH as root.
• Changing the port but forgetting the firewall.

To review your config (via serial or emergency access):

sudo grep -Ev '^\s*#|^\s*$' /etc/ssh/sshd_config

After changes:

sudo systemctl restart ssh

Don’t forget to always test config changes using a second SSH session before closing your current one.

7. Are You Using the Right SSH Port (If Customized)?

If your server is using a non-default port (not 22), make sure to specify it:

ssh -p 2222 user@your.server.ip

Also check that the firewall allows traffic on that custom port.

8. Still Stuck? Use Verbose Logging

When all else fails, let SSH tell you what’s wrong. Run:

ssh -vvv user@server_ip

You’ll see detailed logs of key exchanges, authentication attempts, and where it fails.

It’s noisy, but it’s the fastest way to spot issues like “wrong key,” “host unreachable,” or “auth method not allowed.”

The key is to work methodically:

• Start at the network (can you reach the host?)
• Then the service (is SSH running?)
• Then credentials and permissions (are keys and users correct?).

Next time SSH says “Connection refused” or “Permission denied”, just walk down this list and you’ll have your server back in no time.

[embed]10 Linux Hardening Scripts Every DevSecOps Engineer Can Use practical, idempotent Bash scripts you can drop into a repo and rundevsecopsai.today

[embed]11 hidden gems of systemd systemd is much more than “start and stop”medium.com

Don’t waste valuable time writing Bash scripts from scratch.

The **DevOps Automation Pack gives you 60+ plug-and-play **production-ready Bash scripts for backups, monitoring, security, cleanup, and more.

Every script is cron-ready, supports dry-run mode, and works right out of the box. 👉 Get your copy →