SSH hangs since recent upgrade

Creating a bug report/issue

Required Information

  • DietPi version | cat /boot/dietpi/.version
  • Distro version | echo $G_DISTRO_NAME $G_RASPBIAN
  • Kernel version | uname -a
  • SBC model | echo $G_HW_MODEL_NAME or (EG: RPi3)
  • Power supply used | (EG: 5V 1A RAVpower)
  • SD card used | (EG: SanDisk ultra)

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

Expected behaviour

Actual behaviour

Extra details

  • Sorry, I can’t provide many details about installation, because, well, I can’t get into the OS.
    I have several RPi0Ws running DietPi smoothly.some were installed with DietPi a year ago, and one as recently as last week. They all are functioning fine, except SSH.
    They are all running openssh. When i try to login, they connect fine, and ask for a password. But then just nothing, all of them. There is one RPi3B that i have not yet updated and I can login fine. The updates that caused the problem happened within the last week.

  • All the versions were Buster.
    i would like to investigate further, but there is no way to shut down the Pi’s safely to move them to a monitor and reboot.

Welcome to our community.

I don’t think it is the DietPi update directly that cause the issue. Maybe there was a kernel or apt package update that was triggert in due to the update process. Even if you don’t have access to the system, you would need to reboot them by pulling the plug. Otherwise, you will not be able to further investigate.

On the still running system, you could execute apt update to check on available packages to be updated.

The issue appeared after a reboot after the update, or immediately without a reboot for new SSH connections?

Since the active SSH connection stays active, it could be used to check for error messages and upgrade/downgrade individual packages and test whether it breaks/fixes new parallel SSH connections, to narrow it down. A little risky though, so have either screen+keyboard or a full system drive package to be able to revert if somehow the active SSH session breaks :wink:.

It was after a reboot, in every case, I believe.
But, I cannot really ssh into the machine to do anything. It just hangs on login.

Try to connect monitor and screen to get local access

I meant the last functional RPi 3B, hence the precautions.

Ah, another question: Which SSH client do you use? There should be an immediate error, and it shouldn’t happen within a stable Debian release cycle, but in theory an upgrade of the SSH server could have hardened the allowed key exchange or host key algorithm, or the config file was overwritten, disabling password login for root.

Was it actually the root user you tried to login, and did you try another user, e.g. dietpi?

I am using OpenSSH, and as root. It asks for the password, and then nothing, not even an error message.

Did you tried user dietpi?

That did not work, but I think that I found the problem, and it had nothing to do with dietpi.
It really threw me off, because it was only those devices running dietpi that showed problems, but it was a network problem. An RPi3B that was running my unifi controller started flaking out. I thought that it was
the uSD card, but after many attempts at reinstalling, I came to the conclusion that it was the pi itself.

So I spun up a docker container on the Wyse running my home assistant containers, restored it and now the network is working again. For some reason that got the dietpis working again. Don’t understand why, but network problems often do mysterious things.

Many thanks to everyone here who had suggestions to troubleshoot.!