Can’t ssh in - timeout

Creating a bug report/issue

Required Information

  • DietPi version | 8.13
  • Distro version | Buster
  • SBC model | RPi 4
  • Power supply used | Poe+ to splitter. 20w max at 5v.
  • SD card used | Kingston 128GB SATA SSD

Additional Information (if applicable)

  • Software title | (EG: Nextcloud)
  • Was the software title installed freshly or updated/migrated?
  • Can this issue be replicated on a fresh installation of DietPi?
    ← If you sent a “dietpi-bugreport”, please paste the ID here →
  • Bug report ID | echo $G_HW_UUID

Steps to reproduce

Try to SSH in from any computer: ssh dietpi@

Expected behaviour

SSH connection should establish

Actual behaviour

Connection times out

Extra details

I can ping the IP address from multiple machines and have confirmed that the IP is correct in my router (PFsense). Everything appears to boot correctly when I connect a monitor and keyboard. SSH is running per systemctl. Restarting the device or SSH service didn’t do anything. I can SSH from the RPi 4 to other devices.

The RPi and devices I’m trying to SSH from are on the same LAN segment ( UFW is disabled on the Pi.

ssh -v returns the error connection timed out.

I’m not sure what my next steps should be.

What SSH server you are running. The default one or did you switch to OpenSSH?


I’m not sure exactly when this started. We had a series of outages and my router died and a few days after when I finally got back to this I couldn’t ssh in. I had restored my router from a recent backup, so everything was set up the same. Pi is getting a fixed IP through DHCP.

I’ve also found that I can’t access any services on the pi like DietPi Dashboard, the connection times out too, so maybe this isn’t just an SSH issue. The internet connection test in DietPi config is successful if that means anything.

Sounds like an IP issue. Maybe it’s better to config a fixed IP inside DietPi (of course outside of the DHCP range of the router) and don’t use a DHCP reservation.

Can you run ip a, with that can you check if your device has still the same IP as before.

yes, pls ensure there is no IP address conflict. Means another device have same/ duplicate IP. On the system itself, have a look to SSH server logs

journalctl -u ssh.service

I set a static IP through dietpi-config but no luck. There is no IP conflict that I can find.

Journalctl reports that ssh is listening on port 22.

I tried reinstalling OpenSSH, which didn’t work, and then removing that and installing dropbear, which also didn’t work.

did you have any firewall like UFW active on your system?

Can you try to SSH into your own system if you are login on your system locally


Typo, it’s ssh
Can you ping the dietpi IP from other lan hosts?
Can you ping from the pi the other hosts?

I can SSH into every device I’ve tried to SSH into the Pi with using ssh or 192.168.12.x (client IP) without issue. I can SSH from the Pi to itself using ssh or

I can ping the pi at from any device on the network and can ping any device on the network from the Pi. I can also ping and from the Pi.

I had UFW set up with rules that seemed like they should work, but disabled it just in case. I didn’t see any difference once it was disabled.

I also tried setting a different static IP on the Pi that has never had a DHCP reservation used in pfSense and is outside my dynamic DHCP range. Also no luck.

At this point I’m probably just going to wipe things and start over.

Before you wipe it, try these:
sudo ss -tunlp | grep 22
What is the firewall?
iptables-save -c
Finally do you see the ssh packets?
sudo apt update; sudo apt install tcpdump; tcpdump -i eth0 -c 20 -vn tcp port 22 and host

Or go to uninstall ufw completely

Well this is surprising. sudo apt purge ufw did it. I’m not sure why disabling it didn’t work.

Just in case it’s useful for anyone in the future:
sudo ss -tunlp | grep 22 gave users:(("dropbear","pid=665","fd=4")

iptables-save -c gave a massive output that I can’t easily transfer since I don’t have a browser set up on the Pi. There wasn’t anything that looked suspicious to me in the output though.

sudo apt update; sudo apt install tcpdump; tcpdump -i eth0 -c 20 -vn tcp port 22 and host gave listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes followed by the output as I tried to connect (and was successful, since this was after purging UFW) and then

20 packets captured 
21 packets received by filter 
0 packets dropped by kernel

So I’m not clear on the cause of this, but it’s fixed. Thank you all for your help with my non-Dietpi related questions.

ufw is not the firewall itself, but the frontend. It is using iptables (or maybe nftables) so you can verify if it is really applied or not by checking the iptables output, e.g iptables-save -c
Furthermore, I am not sure if disabling the firewall changes the default policy too.

1 Like

Sorry, reopening this. SSH stopped working again and the cause is unclear.

Went through the above steps and got similar outputs. UFW never got reinstalled, nothing looks weird in iptables and there’s nothing in the pfsense firewall logs.

I can ssh from the pi to any machine, including itself. Any attempt to ssh into it from another machine times out, including if I ssh from the pi to another client and then try to ssh back to the pi.

Any other ideas?

What is the output of:
sudo ss -tunlp | grep 22; sudo iptables-save -c ; ip -4 addr; ip -4 ro list table all; ip -4 ru
Then run again the tcpdump command
sudo tcpdump -i eth0 -c 20 -vn tcp port 22 and host
and try to connect to dietpi.