SSH Stop working : Network error connection refused

Hello I have a VERY WEIRD problem with 3 dietpi headless / serial connection not enabled
=> Network error connection refused

latest Dietpi version

1x Rpi 3a+, just had the time to install fresh version of Diepi, than I got the “Network error connection refused” after reboot
I tried again, a new fress install on a second Rpi 3a+ and got exactly the same issue.

I plugged in an other Rpi 3b+ with its own SD (that was still working yesterday), and got exactly the same issue, impossible to connect anymore !

In each case I see the IP address (Fing Oveerlook) and I can still access the logitech media server web page…

I erased the cache from my putty on Windows, tried from another Windows PC, Switched off and restarted my internet router, no way !

I tryed another router, not connected to Internet and from none of the peripherals had ever been connected to, still
Network error connection refused, although I got the IP address of each peripherals.

In other words, I can’t access anymore my long time running setup and I can’t install new setups !

:cry: :cry: :cry: :cry: :cry:

Do you have any hints to recover the connection and most important to avoid this problem in the future ?



It looks like I’m the only person experimenting this issue.

The fact is that in the meantime I did a fresh Raspbian install and did not get any issue.
So, that’s a problem with dietpi.

I really hate not understanding, it should not be black magic after all.
So should anyone has an idea of the why, I would appreciate.

Thank you.


Strange problem!

You said, you can successfully access other network services provided on your devices, but not ssh, correct?

Did you tried to ping the devices running DietPi? What was the result?

Do you have the chance to recover the log files from the DietPi devices, e.g. “journalctl -u ssh”? Do you see any error logs that may correspond to your problem?

Regards, rasputin

Hello Rasputin,

Thank you for taking care. :sunglasses:

Yes, you got it right, I can sort of ping the Pi as the Pi IP adress is seen by IP scanners and I can access the Media server that is running on the Pi.
Alas, as i didn’t allow serial access, I can’t investigate.

Anyway, TBH, I will not investigate further, I already lost too much time on that.
The only thing I’m thinking about that could result in such behaviour is Fail2Ban that was running on all these install

I’ve erased the SD card, as I couldn’t do anything and I will test a new fresh install without Fail2Ban.

Best regards,


I made a fresh new install, WITHOUT FAIL2BAN
And I got the exact same issue !
It happened just after that I changed the priorities, nice etc… with the dietpi-process_tool utility
I did the change and it corrupted my setup.

I hope you can make a fix.


On my last setup I was wise to keep Serial connection so I just tried again to connect to my latest setup with a serial connection.
OK, I get access.
(Note that I should have thought of moding the DietPi/config.txt manually, it would have saved me a lot of time)

I had a look at the Dropbear service and found it inactive !
I made it active again and could connect through putty port 22.
However after each reboot, I get the same issue, meaning that the dropbear is again inactive and I have to activate it through Serial connection.

The result of : journalctl -u ssh
– No entries –

So now the questions are :

  • Why does dropbear can suddently become inactive without any inteaction from the user side ?

  • How can I definitively fix that issue ?


Strange, that “journalctl -u ssh” returns no logs on your machine. I am using OpenSSH. I see the start of the service in journalctl:

Jul 18 12:41:40 rasputin systemd[1]: Starting OpenBSD Secure Shell server...
Jul 18 12:41:40 rasputin sshd[2012]: Server listening on port 22.
Jul 18 12:41:40 rasputin sshd[2012]: Server listening on :: port 22.
Jul 18 12:41:40 rasputin systemd[1]: Started OpenBSD Secure Shell server.
Jul 18 12:42:59 rasputin sshd[2402]: Accepted publickey for ...

I would expect that journalctl returns similar logs on your machine that show Dropbear has started. And I would expect logs when Dropbear transits to “inactive” …

Did you tried “systemctl status ssh” right before restarting Dropbear to get any hint what could cause the problem?

Regards, rasputin

Hi bricolodu13!

Can you try the command “journalctl | grep ssh” instead of “journalctl -u ssh”?

Regards, rasputin

What exactly did you do?


Although I could find some ways to avoid this problem, I would like to inform you that there is still a bug.
In fact there are a few.

  • 1 Dropbear desactivated after cpu allocation
    2 Console with no login prompt
    3 Console no more activated

Dropbear desactivated after cpu allocation:
I confirm that this bug is still active since around 6.12

I have just tested it on the latest Dietpi version, headless, fresh minimal install, It is easy to replicate:
From ssh console, in DietPi-process_tool : change the CPU allocation of dropbear
When done, that’s it, no more access.
To solve the issue, one need to completely uninstall dropbear from the serial console, reboot and reinstall dropbear.
see the error reported (attachement)

I also encountered Console with no login prompt but can’t remember exactly what was involved

I also encountered Console unactivated which is quite annoying should you can’t access through ssh…

Keep going with the good job.

I am not able to reproduce this problem.
I remember in the past I changed the CPU Affinitiy, Sch. Policy, etc for processes, including dropbear and it never hanged.
I just tried it now and it still is responsive after restarting the dropbear service.

dietpi@odroid:[~]$ cat /etc/systemd/system/dropbear.service.d/dietpi-process_tool.conf
# WARNING: Do not manually edit this file, use "dietpi-services" to adjust values!

Thank you for trying.

Each of my setups, even bare minimal experience the same since long time ago…

I’m the expert in having strange bugs not only software ones…

Same problem for me happened 2 times.

Can’t access from ssh, and other services (http, samba…).
Connecting monitor to hdmi : no signal.
But pings replied…

I am on RPi 3 Model B (armv7l) - DietPi v6.30.0 , issue happened at same time when very huge nzb downloaded from sabnzb.

I think it’s cpu or ram issue, when sabnzb calculate all file before doing extract.
After 4 hours I decided to power off/on rpi, at now par2 it taking a lot of cpu and memory usage

I sent a bug report if it has any information, reference code: 1b578e79-c7bf-44af-9d97-4ca47016f2e0

possibly that you are running out of CPU/Memory. As well I/O could be an issue. Are you going to download to an external device/HDD? If yes, which file system format did it use?

Thanks for replying very fast :slight_smile:

Yes, I have set Dietpi userdata to external usb drive, it’s a RAID 5 formated in ext4.

ok for testing purposes could you attach some USB stick and format it using ntfs and us it as target directory?

For now I have other huge item into sabznb queue. I think I have an external USB drive formated in ntsf.
I can test it, but this will take days.

Why ext4 formated drive should be a problem ?

it’s just an idea based on this GitHub post
Not sure if it will help but something we can try out

I read all issue messages, yes it very interesting and similar.

But it happened 2 times, I downloaded lot of other very huge (and similar files like today) with sabnzb without errors. :confused:

Did you think I can install netdata to monitor and keep history for log etc. ?

I was never using netdata. So not sure what type of history it will keep.