SSH - Never get to prompt !

Troubleshooting
1

Hi There,

A second issue on my DietPi. First one is TimeSync, not resolved yet!

If I ssh, from putty on a Win10 PC on the same network. I never get a prompt.

login as: root
root@192.168.10.3’s password:
Linux DietPi 5.4.72+ #1356 Thu Oct 22 13:56:00 BST 2020 armv6l

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Sun Nov 22 13:24:49 2020

The message gets displayed around 30seconds after I enter the password, then no prompt.

At one point, putty will timeout.

journalctl -ex shows that the password is accepted and the session opened.

But no prompt… now after 7 minutes!

htop is showing my session and low cpu

Any thoughts?

2

Did you tried with a different SD card? Do you use WiFi or Ethernet? Can you check for kernel messages dmesg -l err,crit,alert,emerg

3

Thanks for reply,

Right after the creation of the SD card (second time), SSH worked ok, but after around 1 day, stopped working

The Pi zero W is connected to Wifi

Here’s the output of dmesg

IMG_20201122_143000.jpg
IMG_20201122_143000.jpg3749×621 417 KB

I have not tried another SD card, only have one for now.

Running a check & repair disk with dietpi-drive_manager and reboot… did not see any messages, unsure if it ran?

Did ran a 100MiB benchmark… The SD writes at 4 MiB/s and reads at 21 MiB/s.

4

you could check status of SSH server systemctl status dropbear.service

As well, can you check if your network connection is stable?

5

I’m running OpenBSD SSH and the status is OK

The network is stable and fast, testing with ping to and from Pi

Thanks

6

as OpenBSD SSH isn’t part of DietPi, you installed it yourself? correct? Did you stoppen and removed Dropbear before?

7

Here’s the output of journalctl

IMG_20201122_162538.jpg
IMG_20201122_162538.jpg3894×1174 723 KB

I installed DietPi in a Hyper-V VM… no issue with SSH and Time sync. A bit faster on my i7-32gig than a Pi zero!

Fun debug here!

8

well this is the output for ssh for which you open the other topic :wink:
I will move it over

9

question: How does SSH behave if you stick to DietPi default Dropbear and did not change it towards OpenBSD SSH. If possible try with a fresh image.

10

I experienced the issue with a previous image + dropbear.

I will go back to dropbear on the new image and report

11

ok… I went through the change from openssh to dropbear using dietpi-config… rebooted

I cannot even connect to the IP on port 22…

htop show clearly : /usr/bin/dropbear -p22 -w 65536

  • Maybe the bear went to hibernation!!! :wink:

journalctl -f does not show any connection.

  • I tested on the Hyper-V test image of DietPi…

Trying to verify everything through dietpi-software and I get stuck with the other issue (ntp timeout)

I will take a break from this before I put the whole thing in the garbage can!

Thanks for all the help Joulinar

12

I should mention that Node-Red and MQTT are running fine on the Pi zero without an issue and doing network monitoring and talking to Iot/ESP8266 devices on my local network.

13

strange your system :thinking:

you could check what ist LISTEN on port 22

ss -tulpn | grep LISTEN
14

What’s the expression… give it time it will work?

So after a good night sleep, I can this morning putty/ssh to the PI zero!

Here’s the output of ss:
root@DietPi:~# ss -tulpn | grep LISTEN

tcp LISTEN 0 1000 0.0.0.0:22 0.0.0.0:* users:((“dropbear”,pid=1545,fd=3))
tcp LISTEN 0 511 0.0.0.0:1880 0.0.0.0:* users:((“node-red”,pid=541,fd=22))
tcp LISTEN 0 100 0.0.0.0:1883 0.0.0.0:* users:((“mosquitto”,pid=536,fd=5))
tcp LISTEN 0 1000 [::]:22 [::]:* users:((“dropbear”,pid=1545,fd=4))
tcp LISTEN 0 100 [::]:1883 [::]:* users:((“mosquitto”,pid=536,fd=6))

I got to this point in the different iterations of updates, I will see this thing keep working over time!

Thanks for your help Joulinar Take care.

15

You have way too many bytes in Send-Q

Send-Q The count of bytes not acknowledged by the remote host.

Run the command a few more times to verify if this was a glitch or the norm.

16

SimonFili
means you SSH access is working now?

17

trendy Here’s the output of ss with headers ran a few times after a fresh reboot

root@DietPi:~# ss -tulpn
Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port
tcp LISTEN 0 1000 0.0.0.0:22 0.0.0.0:* users:((“dropbear”,pid=519,fd=3))
tcp LISTEN 0 511 0.0.0.0:1880 0.0.0.0:* users:((“node-red”,pid=538,fd=22))
tcp LISTEN 0 100 0.0.0.0:1883 0.0.0.0:* users:((“mosquitto”,pid=533,fd=5))
tcp LISTEN 0 1000 [::]:22 [::]:* users:((“dropbear”,pid=519,fd=4))
tcp LISTEN 0 100 [::]:1883 [::]:* users:((“mosquitto”,pid=533,fd=6))

Joulinar
Yes, SSH now works fine after a few days and reboots.

Unsure why 1) it was not working with dropbear on the first image 2) why openssh did not work on the second image then 3) dropbear took 12h to start working on the second image.

A very weird system like you said before. Now going to test why the NTP does not work and report on the other thread.

18

I would also check the interfaces for errors, cables, ports, switches etc. All these bytes in Send-Q are not normal.

19

trendy
To which data you are referring to?

20

Joulinar to the Send-Q bytes column.