SSH - Never get to prompt ! Topic is solved

[SimonFili]

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!!!

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

[SimonFili]

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.

[Joulinar]

strange your system

you could check what ist LISTEN on port 22

Code: Select all

ss -tulpn | grep LISTEN

[SimonFili]

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.

[trendy]

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.

[Joulinar]

@SimonFili
means you SSH access is working now?

[SimonFili]

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

[trendy]

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

[Joulinar]

@trendy
To which data you are referring to?

[trendy]

@Joulinar to the Send-Q bytes column.