Random ssh access

Creating a bug report/issue

I have searched the existing open and closed issues

Required Information

  • DietPi version | cat /boot/dietpi/.version
  • Distro version | echo $G_DISTRO_NAME $G_RASPBIAN
  • Kernel version | uname --all
  • Architecture | dpkg --print-architecture
  • 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

Description of the problem

I experiment a very strange issue as I must issue several times the command ssh to access against Dietpi to finally access it.

The RockPro64 machine is not running out of memory and has enough disk space. I run avahi-daemon. The macbook machine accessing it uses a fixed IP address: 192.168.129.0 and dietpi has the IP address: 192.168.1.200

It seemed that this issue is happening since I upgraded Debian to Trixie but I’m not fully sure at 100%.

❯ ssh -o ConnectTimeout=30 -o ServerAliveInterval=15 root@dietpi.local
Linux DietPi 6.18.26-current-rockchip64 #1 SMP PREEMPT Thu Apr 30 09:13:53 UTC 2026 aarch64

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.
 ─────────────────────────────────────────────────────
 DietPi v10.3.3 : 13:28 - Wed 05/06/2026
 ─────────────────────────────────────────────────────
 - Device model : ROCKPro64 (aarch64)
 - CPU temp : 36 Β°C / 96 Β°F : Cool runnings
 - LAN IP : 192.168.1.200 (eth0)
 - MOTD : Please read this info about mitigating CVE-2026-31431 aka "Copy Fail" on DietPi:
          https://github.com/MichaIng/DietPi/issues/8122
 ─────────────────────────────────────────────────────

 DietPi Team     : https://github.com/MichaIng/DietPi#the-dietpi-project-team
 Image by        : DietPi Core Team (pre-image: Armbian)
 Patreon Legends : ADSB.im, Oliver C. Radke
 Website         : https://dietpi.com/ | https://x.com/DietPi_ | Bsky: @dietpi.com
 Contribute      : https://dietpi.com/contribute.html
 Web Hosting by  : https://login-online.com/

 dietpi-launcher : All the DietPi programs in one place
 dietpi-config   : Feature rich configuration tool for your device
 dietpi-software : Select optimised software for installation
 htop            : Resource monitor
 cpu             : Shows CPU information and stats

root@DietPi:~# df -h
Filesystem      Size  Used Avail Use% Mounted on
udev            1.9G     0  1.9G   0% /dev
tmpfs           386M  5.8M  380M   2% /run
/dev/mmcblk2p1   29G  8.6G   20G  31% /
tmpfs           1.9G  100K  1.9G   1% /dev/shm
tmpfs           5.0M   12K  5.0M   1% /run/lock
tmpfs           1.0M     0  1.0M   0% /run/credentials/systemd-journald.service
tmpfs           1.9G     0  1.9G   0% /tmp
tmpfs            50M   16K   50M   1% /var/log
tmpfs           1.0M     0  1.0M   0% /run/credentials/getty@tty1.service
tmpfs           386M  4.0K  386M   1% /run/user/0
root@DietPi:~# free -m
               total        used        free      shared  buff/cache   available
Mem:            3852         186        3545           5         197        3666
Swap:              0           0           0
root@DietPi:~# exit
logout
Connection to dietpi.local closed.

~/code/_temp/opencode on dev β€’
❯ ssh -o ConnectTimeout=30 -o ServerAliveInterval=15 root@dietpi.local
kex_exchange_identification: read: Operation timed out
banner exchange: Connection to 192.168.1.200 port 22: Operation timed out

~/code/_temp/opencode on dev β€’
❯ ssh -o ConnectTimeout=90 -o ServerAliveInterval=15 root@dietpi.local
kex_exchange_identification: read: Operation timed out
banner exchange: Connection to 192.168.1.200 port 22: Operation timed out

~/code/_temp/opencode on dev β€’
❯ ssh -o ConnectTimeout=300 -o ServerAliveInterval=15 root@dietpi.local
kex_exchange_identification: read: Operation timed out
banner exchange: Connection to 192.168.1.200 port 22: Operation timed out

~/code/_temp/opencode on dev β€’
❯ ssh -o ConnectTimeout=300 -o ServerAliveInterval=15 root@dietpi.local
kex_exchange_identification: read: Operation timed out
banner exchange: Connection to 192.168.1.200 port 22: Operation timed out

~/code/_temp/opencode on dev β€’
❯ ssh root@dietpi.local
kex_exchange_identification: read: Operation timed out
banner exchange: Connection to 192.168.1.200 port 22: Operation timed out

~/code/_temp/opencode on dev β€’
❯ ssh root@dietpi.local
kex_exchange_identification: read: Operation timed out
banner exchange: Connection to 192.168.1.200 port 22: Operation timed out

~/code/_temp/opencode on dev β€’
❯ ssh root@dietpi.local
Linux DietPi 6.18.26-current-rockchip64 #1 SMP PREEMPT Thu Apr 30 09:13:53 UTC 2026 aarch64

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: Wed May  6 13:28:54 2026 from 192.168.129.0
 ─────────────────────────────────────────────────────
 DietPi v10.3.3 : 13:34 - Wed 05/06/2026
 ─────────────────────────────────────────────────────
 - Device model : ROCKPro64 (aarch64)
 - CPU temp : 36 Β°C / 96 Β°F : Cool runnings
 - LAN IP : 192.168.1.200 (eth0)
 - MOTD : Please read this info about mitigating CVE-2026-31431 aka "Copy Fail" on DietPi:
          https://github.com/MichaIng/DietPi/issues/8122
 ─────────────────────────────────────────────────────

 DietPi Team     : https://github.com/MichaIng/DietPi#the-dietpi-project-team
 Image by        : DietPi Core Team (pre-image: Armbian)
 Patreon Legends : ADSB.im, Oliver C. Radke
 Website         : https://dietpi.com/ | https://x.com/DietPi_ | Bsky: @dietpi.com
 Contribute      : https://dietpi.com/contribute.html
 Web Hosting by  : https://login-online.com/

 dietpi-launcher : All the DietPi programs in one place
 dietpi-config   : Feature rich configuration tool for your device
 dietpi-software : Select optimised software for installation
 htop            : Resource monitor
 cpu             : Shows CPU information and stats

you would need to check ssh server logs on target system if there is anything related to ssh connections.

I don’t see error using the journal

root@DietPi:~# journalctl -u ssh
May 06 13:06:17 DietPi systemd[1]: Starting ssh.service - OpenBSD Secure Shell server...
May 06 13:06:17 DietPi sshd[605]: Server listening on 0.0.0.0 port 22.
May 06 13:06:17 DietPi sshd[605]: Server listening on :: port 22.
May 06 13:06:17 DietPi systemd[1]: Started ssh.service - OpenBSD Secure Shell server.
May 06 13:06:37 DietPi sshd-session[707]: Accepted publickey for root from 192.168.129.0 port 61990 ssh2: RSA SHA256:E0Pyrm0oJ1n1ugwsAHVeYhT5f7qRbD7xm3Sd57fn4Tg
May 06 13:06:37 DietPi sshd-session[707]: pam_unix(sshd:session): session opened for user root(uid=0) by root(uid=0)
May 06 13:28:54 DietPi sshd-session[898]: Accepted publickey for root from 192.168.129.0 port 62399 ssh2: RSA SHA256:E0Pyrm0oJ1n1ugwsAHVeYhT5f7qRbD7xm3Sd57fn4Tg
May 06 13:28:54 DietPi sshd-session[898]: pam_unix(sshd:session): session opened for user root(uid=0) by root(uid=0)
May 06 13:34:19 DietPi sshd-session[940]: Accepted publickey for root from 192.168.129.0 port 62613 ssh2: RSA SHA256:E0Pyrm0oJ1n1ugwsAHVeYhT5f7qRbD7xm3Sd57fn4Tg
May 06 13:34:19 DietPi sshd-session[940]: pam_unix(sshd:session): session opened for user root(uid=0) by root(uid=0)
May 06 14:10:52 DietPi sshd[605]: Received signal 15; terminating.
May 06 14:10:52 DietPi systemd[1]: Stopping ssh.service - OpenBSD Secure Shell server...
May 06 14:10:52 DietPi systemd[1]: ssh.service: Deactivated successfully.
May 06 14:10:52 DietPi systemd[1]: Stopped ssh.service - OpenBSD Secure Shell server.
May 06 14:10:52 DietPi systemd[1]: Starting ssh.service - OpenBSD Secure Shell server...
May 06 14:10:52 DietPi sshd[1102]: Server listening on 0.0.0.0 port 22.
May 06 14:10:52 DietPi sshd[1102]: Server listening on :: port 22.
May 06 14:10:52 DietPi systemd[1]: Started ssh.service - OpenBSD Secure Shell server.
May 06 14:10:59 DietPi sshd-session[1106]: Accepted publickey for root from 192.168.129.0 port 62898 ssh2: RSA SHA256:E0Pyrm0oJ1n1ugwsAHVeYhT5f7qRbD7xm3Sd57fn4Tg
May 06 14:10:59 DietPi sshd-session[1106]: pam_unix(sshd:session): session opened for user root(uid=0) by root(uid=0)
May 06 14:14:11 DietPi sshd-session[1141]: Accepted publickey for root from 192.168.129.50 port 62952 ssh2: RSA SHA256:E0Pyrm0oJ1n1ugwsAHVeYhT5f7qRbD7xm3Sd57fn4Tg
May 06 14:14:11 DietPi sshd-session[1141]: pam_unix(sshd:session): session opened for user root(uid=0) by root(uid=0)
May 06 14:16:07 DietPi sshd-session[1179]: Accepted publickey for root from 192.168.129.0 port 63012 ssh2: RSA SHA256:E0Pyrm0oJ1n1ugwsAHVeYhT5f7qRbD7xm3Sd57fn4Tg
May 06 14:16:07 DietPi sshd-session[1179]: pam_unix(sshd:session): session opened for user root(uid=0) by root(uid=0)
May 06 14:53:57 DietPi sshd-session[1338]: Accepted publickey for root from 192.168.129.0 port 63648 ssh2: RSA SHA256:E0Pyrm0oJ1n1ugwsAHVeYhT5f7qRbD7xm3Sd57fn4Tg
May 06 14:53:57 DietPi sshd-session[1338]: pam_unix(sshd:session): session opened for user root(uid=0) by root(uid=0)

usually this means the system is not reached. You are sure there is no duplicate IP within your network? Another option would be to use tcdump or similar to trace the connections from both ends.

tcpdump got many packets. Do I have to save the file and share it ?

It is best to use a client system that is not yet connected to the target. This prevents the existing connection from being traced back. This allows you to restrict the port and source to the actual login attempt.

tcpdump -i any -c500 -nn port <number> and src <ip.address>

Here is what I got when no ssh connection happened

❯ sudo tcpdump -i any -c500 -nn port 22 and src 192.168.1.200
Password:
tcpdump: data link type PKTAP
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on any, link-type PKTAP (Apple DLT_PKTAP), snapshot length 524288 bytes
17:07:51.964345 IP 192.168.1.200.22 > 192.168.129.0.49879: Flags [S.E], seq 1777140458, ack 1327651843, win 65160, options [mss 1460,sackOK,TS val 3342880106 ecr 1197062337,nop,wscale 9], length 0
17:07:52.969304 IP 192.168.1.200.22 > 192.168.129.0.49879: Flags [S.E], seq 1777140458, ack 1327651843, win 65160, options [mss 1460,sackOK,TS val 3342881111 ecr 1197062337,nop,wscale 9], length 0
17:07:54.985247 IP 192.168.1.200.22 > 192.168.129.0.49879: Flags [S.E], seq 1777140458, ack 1327651843, win 65160, options [mss 1460,sackOK,TS val 3342883127 ecr 1197062337,nop,wscale 9], length 0
17:07:59.081188 IP 192.168.1.200.22 > 192.168.129.0.49879: Flags [S.E], seq 1777140458, ack 1327651843, win 65160, options [mss 1460,sackOK,TS val 3342887223 ecr 1197062337,nop,wscale 9], length 0
17:08:07.273140 IP 192.168.1.200.22 > 192.168.129.0.49879: Flags [S.E], seq 1777140458, ack 1327651843, win 65160, options [mss 1460,sackOK,TS val 3342895415 ecr 1197062337,nop,wscale 9], length 0
17:08:19.297588 IP 192.168.1.200.22 > 192.168.129.0.49895: Flags [S.E], seq 3931075097, ack 2217403900, win 65160, options [mss 1460,sackOK,TS val 2686572757 ecr 2468158836,nop,wscale 9], length 0
17:08:20.328922 IP 192.168.1.200.22 > 192.168.129.0.49895: Flags [S.E], seq 3931075097, ack 2217403900, win 65160, options [mss 1460,sackOK,TS val 2686573789 ecr 2468158836,nop,wscale 9], length 0
17:08:22.344878 IP 192.168.1.200.22 > 192.168.129.0.49895: Flags [S.E], seq 3931075097, ack 2217403900, win 65160, options [mss 1460,sackOK,TS val 2686575805 ecr 2468158836,nop,wscale 9], length 0
17:08:23.401089 IP 192.168.1.200.22 > 192.168.129.0.49879: Flags [S.E], seq 1777140458, ack 1327651843, win 65160, options [mss 1460,sackOK,TS val 3342911543 ecr 1197062337,nop,wscale 9], length 0

and when that worked

17:09:07.483021 IP 192.168.1.200.22 > 192.168.129.0.49952: Flags [P.], seq 1:42, ack 1, win 128, options [nop,nop,TS val 2657653691 ecr 3067321247], length 41: SSH: SSH-2.0-OpenSSH_10.0p2 Debian-7+deb13u2
17:09:07.767464 IP 192.168.1.200.22 > 192.168.129.0.49952: Flags [.], ack 23, win 128, options [nop,nop,TS val 2657653976 ecr 3067328695], length 0
17:09:07.768695 IP 192.168.1.200.22 > 192.168.129.0.49952: Flags [.], ack 1471, win 126, options [nop,nop,TS val 2657653977 ecr 3067328697], length 0
17:09:07.769974 IP 192.168.1.200.22 > 192.168.129.0.49952: Flags [.], ack 1591, win 126, options [nop,nop,TS val 2657653978 ecr 3067328698], length 0
17:09:07.807984 IP 192.168.1.200.22 > 192.168.129.0.49952: Flags [P.], seq 42:1082, ack 1591, win 126, options [nop,nop,TS val 2657654016 ecr 3067328698], length 1040
17:09:07.818508 IP 192.168.1.200.22 > 192.168.129.0.49952: Flags [P.], seq 1082:1614, ack 1671, win 126, options [nop,nop,TS val 2657654027 ecr 3067328741], length 532

I fixed my issue. I added a new IP address on my Macbook Ethernet port in order to become part of the same network range as the RockPro64 running dietpi => 192.168.1.200

en8: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
	options=6464<VLAN_MTU,TSO4,TSO6,CHANNEL_IO,PARTIAL_CSUM,ZEROINVERT_CSUM>
	ether 30:23:03:e2:0f:e5
	inet6 fe80::1872:92f7:248e:7759%en8 prefixlen 64 secured scopeid 0xd
	inet6 2a02:a03f:c6cb:5801:cb8:e872:9a0a:1e02 prefixlen 64 autoconf secured
	inet6 2a02:a03f:c6cb:5801:5d7f:b365:7eb8:f138 prefixlen 64 autoconf temporary
	inet 192.168.129.0 netmask 0xfffffe00 broadcast 192.168.129.255
	inet 192.168.1.100 netmask 0xffffff00 broadcast 192.168.1.255

and now I can ssh, exit,ssh, etc without issues :slight_smile:

ok good, at least this was one option because your trace shows that the server (192.168.1.200) is repeatedly sending SYN/ACKs, but no final ACK is received from the client, the TCP handshake is not completing. Common causes include NAT/middlebox/Firewall aso. Moving into same network is bypassing this now.

Anyway if you are interested a method to analyse the handshake is describe on this blog post How to Identify Failed TCP Handshakes in Packet Captures