SSH Stop working : Network error connection refused

[bricolodu13]

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 !



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

Best
JB

[bricolodu13]

Hello,

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.
Jean

[rasputin]

Hi!

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

[bricolodu13]

Hello Rasputin,

Thank you for taking care.

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,
Jean

[bricolodu13]

Hello,

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.
Jean

[bricolodu13]

Hello,

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 ?

[rasputin]

Hi!

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

Code: Select all

Jul 18 12:41:40 rasputin systemd[1]: Starting OpenBSD Secure Shell server...
Jul 18 12:41:40 rasputin sshd[2012]: Server listening on 0.0.0.0 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

[rasputin]

Hi bricolodu13!

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

Regards, rasputin

[rasputin]

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.

What exactly did you do?

[bricolodu13]

Hello,

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.