Ssh to Raspberry Pi Zero W timing out

Installing and Using OpenWrt
1

I'm at a bit of a loss here, as I cannot ssh into a Raspberry Pi Zero W, but I am able to use LuCI. Interestingly, LuCI is reasonably responsive, but my goal is to use this device primarily via ssh (more on that later). I'm working entirely headless and via wifi.

I've taken a bog-standard 25.12.3 ext4 install image for the Pi Zero W. I wrote it to the card, booted the device, then took the card out and edited the network and wireless files so that it would connect (as a sta mode device) to my existing wifi network as a DHCP client. I also disabled the DHCP server. There are no other changes.

Pings to the Pi Zero W are totally fine (consistent, not dropping out), LuCI connects without any issues and is performant enough. But ssh is timing out. I am able to ssh to other devices (including a Pi4 running OpenWrt) without issue.

Any ideas why ssh is not working on this device??

Configs:

/etc/config/network 
config interface 'loopback'
	option device 'lo'
	option proto 'static'
	list ipaddr '127.0.0.1/8'

config globals 'globals'
	option dhcp_default_duid '0004798d8126db7a439a806f3e92fce6a88d'
	option ula_prefix 'fd33:e75e:3384::/48'

config interface 'lan'
	option proto 'dhcp'
/etc/config/wireless 
config wifi-device 'radio0'
	option type 'mac80211'
	option path 'platform/soc/20300000.mmcnr/mmc_host/mmc1/mmc1:0001/mmc1:0001:1'
	option band '2g'
	option channel '1'
	option htmode 'HT20'

config wifi-iface 'default_radio0'
	option device 'radio0'
	option network 'lan'
	option mode 'sta'
	option ssid 'REDACTED'
	option encryption 'psk2'
	option key 'REDACTED'
/etc/config/dhcp 
config dnsmasq
	option domainneeded '1'
	option boguspriv '1'
	option filterwin2k '0'
	option localise_queries '1'
	option rebind_protection '1'
	option rebind_localhost '1'
	option local '/lan/'
	option domain 'lan'
	option expandhosts '1'
	option nonegcache '0'
	option cachesize '1000'
	option authoritative '1'
	option readethers '1'
	option leasefile '/tmp/dhcp.leases'
	option resolvfile '/tmp/resolv.conf.d/resolv.conf.auto'
	option nonwildcard '1'
	option localservice '1'
	option ednspacket_max '1232'
	option filter_aaaa '0'
	option filter_a '0'

config dhcp 'lan'
	option interface 'lan'
	option start '100'
	option limit '150'
	option leasetime '12h'
	option dhcpv4 'server'
	option ignore '1'


config dhcp 'wan'
	option interface 'wan'
	option ignore '1'

config odhcpd 'odhcpd'
	option maindhcp '0'
	option leasefile '/tmp/odhcpd.leases'
	option leasetrigger '/usr/sbin/odhcpd-update'
	option loglevel '4'
	option piodir '/tmp/odhcpd-piodir'
	option hostsdir '/tmp/hosts'
/etc/config/firewall 
config defaults
	option syn_flood	1
	option input		REJECT
	option output		ACCEPT
	option forward		REJECT
# Uncomment this line to disable ipv6 rules
#	option disable_ipv6	1

config zone
	option name		lan
	list   network		'lan'
	option input		ACCEPT
	option output		ACCEPT
	option forward		ACCEPT

config zone
	option name		wan
	list   network		'wan'
	list   network		'wan6'
	option input		REJECT
	option output		ACCEPT
	option forward		DROP
	option masq		1
	option mtu_fix		1

config forwarding
	option src		lan
	option dest		wan

# We need to accept udp packets on port 68,
# see https://dev.openwrt.org/ticket/4108
config rule
	option name		Allow-DHCP-Renew
	option src		wan
	option proto		udp
	option dest_port	68
	option target		ACCEPT
	option family		ipv4

# Allow IPv4 ping
config rule
	option name		Allow-Ping
	option src		wan
	option proto		icmp
	option icmp_type	echo-request
	option family		ipv4
	option target		ACCEPT

config rule
	option name		Allow-IGMP
	option src		wan
	option proto		igmp
	option family		ipv4
	option target		ACCEPT

# Allow DHCPv6 replies
# see https://github.com/openwrt/openwrt/issues/5066
config rule
	option name		Allow-DHCPv6
	option src		wan
	option proto		udp
	option dest_port	546
	option family		ipv6
	option target		ACCEPT

config rule
	option name		Allow-MLD
	option src		wan
	option proto		icmp
	option src_ip		fe80::/10
	list icmp_type		'130/0'
	list icmp_type		'131/0'
	list icmp_type		'132/0'
	list icmp_type		'143/0'
	option family		ipv6
	option target		ACCEPT

# Allow essential incoming IPv6 ICMP traffic
config rule
	option name		Allow-ICMPv6-Input
	option src		wan
	option proto	icmp
	list icmp_type		echo-request
	list icmp_type		echo-reply
	list icmp_type		destination-unreachable
	list icmp_type		packet-too-big
	list icmp_type		time-exceeded
	list icmp_type		bad-header
	list icmp_type		unknown-header-type
	list icmp_type		router-solicitation
	list icmp_type		neighbour-solicitation
	list icmp_type		router-advertisement
	list icmp_type		neighbour-advertisement
	option limit		1000/sec
	option family		ipv6
	option target		ACCEPT

# Allow essential forwarded IPv6 ICMP traffic
config rule
	option name		Allow-ICMPv6-Forward
	option src		wan
	option dest		*
	option proto		icmp
	list icmp_type		echo-request
	list icmp_type		echo-reply
	list icmp_type		destination-unreachable
	list icmp_type		packet-too-big
	list icmp_type		time-exceeded
	list icmp_type		bad-header
	list icmp_type		unknown-header-type
	option limit		1000/sec
	option family		ipv6
	option target		ACCEPT

config rule
	option name		Allow-IPSec-ESP
	option src		wan
	option dest		lan
	option proto		esp
	option target		ACCEPT

config rule
	option name		Allow-ISAKMP
	option src		wan
	option dest		lan
	option dest_port	500
	option proto		udp
	option target		ACCEPT


### EXAMPLE CONFIG SECTIONS
# do not allow a specific ip to access wan
#config rule
#	option src		lan
#	option src_ip	192.168.45.2
#	option dest		wan
#	option proto	tcp
#	option target	REJECT

# block a specific mac on wan
#config rule
#	option dest		wan
#	option src_mac	00:11:22:33:44:66
#	option target	REJECT

# block incoming ICMP traffic on a zone
#config rule
#	option src		lan
#	option proto	ICMP
#	option target	DROP

# port redirect port coming in on wan to lan
#config redirect
#	option src			wan
#	option src_dport	80
#	option dest			lan
#	option dest_ip		192.168.16.235
#	option dest_port	80
#	option proto		tcp

# port redirect of remapped ssh port (22001) on wan
#config redirect
#	option src		wan
#	option src_dport	22001
#	option dest		lan
#	option dest_port	22
#	option proto		tcp

### FULL CONFIG SECTIONS
#config rule
#	option src		lan
#	option src_ip	192.168.45.2
#	option src_mac	00:11:22:33:44:55
#	option src_port	80
#	option dest		wan
#	option dest_ip	194.25.2.129
#	option dest_port	120
#	option proto	tcp
#	option target	REJECT

#config redirect
#	option src		lan
#	option src_ip	192.168.45.2
#	option src_mac	00:11:22:33:44:55
#	option src_port		1024
#	option src_dport	80
#	option dest_ip	194.25.2.129
#	option dest_port	120
#	option proto	tcp
/etc/config/dropbear 
# See https://openwrt.org/docs/guide-user/base-system/dropbear
config dropbear main
	option enable '1'
	option PasswordAuth 'on'
	option RootPasswordAuth 'on'
	option Port         '22'
#	option BannerFile   '/etc/banner'
#	option LocalPortForward 'off'
#	option RemotePortForward 'off'

Also for those curious, the plan I have for this device is to make a small desk fan controllable over the network (via Home Assistant) using the GPIO pins. The fan has a low voltage control board with LED indicators for the speeds and a simple pushbutton for on/off and speed control. I'll have inputs setup to detect the current state of the fan, and an output to actuate its control button. It'll connect via wifi to the network and I'll have a basic script to handle the logic when HA requests the current fan state and/or commands a change. For all of this to work, I need to be able to use ssh normally.

2

What if you first restart dropbear from LuCI and then try ssh?

3

Good thought, but no difference... some logs:

[May 8, 2026 at 10:36:29 PM UTC] authpriv.info: dropbear[653]: Early exit: Terminated by signal
[May 8, 2026 at 10:36:29 PM UTC] authpriv.info: dropbear[2405]: Not backgrounding

Then I tried connecting again via ssh... it was timing out so I canceled but got this:

[May 8, 2026 at 10:36:47 PM UTC] authpriv.info: dropbear[2433]: Child connection from 10.0.1.50:53356
[May 8, 2026 at 10:36:52 PM UTC] authpriv.info: dropbear[2433]: Exit before auth from <10.0.1.50:53356>: Exited normally

However, subsequent connection attempts both timeout and don't produce any log events.

4

Are the /etc/dropbear permissions and ownership correct? Guessing so, since you didn’t build a custom image, but worth checking.

5

Can't check on the running system because no ssh access... womp womp... lol.

But, putting the card into a reader on a Ubuntu box, when I look at the file, it is owned by root/root and has RW permissions on root.

This is as expected per the typical OpenWrt install (for example, from another working device on my network).

6

Is the host using the wrong crypto algorithm or something? I usually debug these by ssh -v -v root@device and dig through ssh's output to see what it doesn't like...

7 
% ssh -vv root@10.0.1.165
debug1: OpenSSH_10.2p1, LibreSSL 3.3.6
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Reading configuration data /etc/ssh/ssh_config.d/100-macos.conf
debug1: /etc/ssh/ssh_config.d/100-macos.conf line 1: Applying options for *
debug1: Reading configuration data /etc/ssh/crypto.conf
debug2: resolve_canonicalize: hostname 10.0.1.165 is address
debug1: Authenticator provider $SSH_SK_PROVIDER did not resolve; disabling
debug1: Connecting to 10.0.1.165 [10.0.1.165] port 22.
debug1: connect to address 10.0.1.165 port 22: Operation timed out
ssh: connect to host 10.0.1.165 port 22: Operation timed out

For reference, the first 7 lines are the same when I connect to my Pi4 (also running 25.12.3), but it obviously connects (no timeout issue).

Also, it would be odd if it was using the wrong crypto suite because it is a bone stock image with no changes aside from the requisite wifi and network (and dhcp) adjustments to get it my wifi network

8

Yeah, that smells of dropbear simply not listening... Does nmap show the port open? I would think so, given the "connecting" message.

$ nmap -p 22 10.0.1.165

PORT   STATE SERVICE
22/tcp open  ssh
9

I don't have nmap installed on my Mac, but I ran it on my OpenWrt Pi4...

root@openwrt:~# nmap -p 22 10.0.1.165
Starting Nmap 7.95 ( https://nmap.org ) at 2026-05-08 18:01 PDT
Nmap scan report for 10.0.1.165
Host is up (0.25s latency).

PORT   STATE    SERVICE
22/tcp filtered ssh
MAC Address: B8:27:EB:6F:C6:AA (Raspberry Pi Foundation)

Nmap done: 1 IP address (1 host up) scanned in 3.31 seconds

Interesting that it is showing filtered. Any idea why that would be? Could that be just an artifact of the timeout issue?

10

Hmm, that's interesting. Is the router blocking access to port 22 on the Zero???

11

Interesting development... I ssh'd from my OpenWrt Pi4, and it has actually connected... but it's incredibly slow....

It's been ~1m and it hasn't finished the ssh session connection.... it's stuck after the Busybox line:

BusyBox v1.37.0 (2026-05-04 22:30:45 UTC) built-in shell (ash)

Not possible given that all of the tests are being run on the same subnet.

UPDATE: a few minutes later, the connection is still stalled per the above.
I'm at a bit of a loss as to why dropbear is not behaving when LuCI is just fine.

12

Sort of reminds me of this older thread, but seemed to be a WiFi bug at the time.

13

Interesting.... seems like it is plausibly the culprit. The frustrating thing is that was resolved for the device in question in a patch that was committed in the snapshots ~22.03.0 timeframe... presumably that patch still exists now in the code for 25.12.

Interestingly, I did try Raspberry Pi OS previously and also encountered ssh issues, but I was thinking that it was because that OS is rather heavy (and considerably heavier than OpenWrt). I should probably check the RPi forums to see what they have on the topic.

Maybe this device just isn't going to work for ssh purposes.

14

I installed luci-app-ttyd so I could get a terminal on this thing...

Interestingly, I can't seem to ssh outbound either (hangs/times out), but I can ssh to localhost and that works fine.

Meanwhile, I also installed curl and then fed it a URL and it was spitting out the page quite quickly (specifically in reference to the speed at which the text was rendered to the screen and it was scrolling pretty fast; I'm sure it's not fast by any measure of actual bandwidth, of course). The point of this test was to prove that there wasn't some sort of fundamental issue with the wifi link itself.... honestly, it all seems fine.

I found some things on general web searches about people who had issues with wifi + ssh, but they seemed to point to things like mesh network incompatibility and the like. But that doesn't apply to my network (I don't use mesh) and there didn't seem to be any consistency for the rest of the reports I saw.

Is ssh really more 'bursty' or otherwise significantly different than other TCP connections that it would conflict with the wifi subsystem on this device? It's so odd.

15

The missing LAN Port of the Zero is a major PITA, to debug stuff.
I use custom images including the usual USB-LAN kmods, such that i can attach a USB LAN dongle after first boot used as eth0 for admin access.

You could also use USB on the go feature as admin back channel, to configure a virtual serial port and then connect the Zero via USB to the PC client (without the On-the-go adapter). Putty is able to connect via that virtual serial port on top of that USB-on-the-go connection. If you have a mac, you cound even configure a virtual network card on that USB-on-the-go connection: OpenWRT on Rasberry Pi in USB-OTG gadget mode

I then tried something similar to your setup. I did it like this, which should be the same as your setup:

  • 25.12.3
  • LAN is bound to eth0 which is an USB-to-LAN dongle for admin access.
  • LAN2 to replicate your scenario, while not conflicting with the admin access on LAN
    • LAN2 is setup for the Zero Wifi, WiFi is connecting as STA to 2.4 Wifi
    • LAN2 is assigned to a firewall zone LAN2 which has 3x accept

I was able to connect both via LuCi And SSH (connecting via 192.168.4.135 - x.x.4.x is my 2.4 Wifi, x.x.x.135 is the address the Zero got from the AP. So it is for sure not accidential access via the admin LAN connection on the USB-LAN-dongle which would have been 192.168.8.1).

I had to disable network isolation on my 2.4 AP.

Ping on 192.168.4.135 worked at once, but both LuCi and SSH did not work at the beginning. Copilot solved it with the hint, to first reset the firewall via "nft flush ruleset" after having changed the input/forward/output rule of the custom-created zone LAN2. But your config files used LAN right away, so that likely was not your problem.

How how amp has your Zero PSU ? I found that a lot of past weird software problems on the Zero got resolved, once i had switched to a 5Vx3A PSU + a powered USB-hub + using a second 5Vx3A PSU for the USB hub. Even though it has very low avg power, it sure has power peaks.

16

Could not agree more. In fact, I personally have probably dissuaded people from using these devices with OpenWrt many times (but in fairness to my stance -- that has been specifically around the Pi Zero/W as a router).

I was trying to do this, but couldn't get the back channel to work. (I got ethernet to work with the RaspberryPi OS, but not OpenWrt). I'll try again with the link you provided.

Is this with the OTG adapter + USB to ethernet dongle, or the "back channel" USB ethernet?

Are you in a position where you could try disconnecting the USB-LAN dongle such that the wifi is the only connection to the network?

I don't use client isolation on my APs, but good point.

Right -- I should not have any firewall issues since everything is on the lan. Furthermore, I also found that ssh'ing out of the Zero W didn't work (I used the LuCI terminal app to connect, then tried to ssh from there).

I'm connected to a Mac mini (M4) via a USB-C to USB microB cable (I don't actually know how the CC lines are configured on this cable, though). Assuming the cable isn't limiting it, I should be able to get ~10W easily. I don't think power issues are likely here, but I'll try a different power source.

17

I got the OTG ethernet gadget mode interface working and I can ssh into that interface without an issue. It's fast and works immediately.

But the ssh via the wifi interface still fails.

I tried a much standalone power adapter that can supply up to 5V @ 2A (it can actually provide up to 18W when used at 9V or 12V). That also made no difference in the ability to ssh into the wifi interface. There is no indication that this is a power related issue, AFAICT.

All the while, LuCI is fast and responsive, as is the LuCI terminal and even ssh'ing to localhost via that terminal.

18

I tried to strip it down to a minimum:

custom firmware packages
(only used, to enable a few USB-LAN dongles, to reduce first access hassle on the Zero)

kmod-usb-net-rtl8150 kmod-usb-net-rtl8152 kmod-usb-net-asix kmod-usb-net-asix-ax88179 kmod-usb2 kmod-usb-ohci kmod-usb-ehci kmod-usb-dwc2 kmod-usb-gadget-eth kmod-usb-net-rndis usb-modeswitch usbutils luci-ssl kmod-w1-slave-therm kmod-w1-master-gpio curl bc kmod-mt7601u parted losetup resize2fs

ucidefaults
(To get my USB-LAN dongle to show up as eth0 on the Zero. "-1" => br-lan)

uci add_list network.@device[-1].ports='eth0'

After flashing and booting the Zero, I can access OpenWRT via the LAN-USB dongle acting as eth0/LAN on 192.168.1.1. Then manually updating the following, to replicate your use case:

network:

config interface 'loopback'
option device 'lo'
option proto 'static'
list ipaddr '127.0.0.1/8'

config globals 'globals'
option dhcp_default_duid '0004b4d4972fefe74bbd825eb246374b3db9'
option ula_prefix 'fd1f:c10a:da21::/48'

config device
option name 'br-lan'
option type 'bridge'
list ports 'eth0' # came from ucidefaults
#-list ports 'wlan0' # manually removed this default value

config interface 'lan'
option device 'br-lan'
option proto 'static'
list ipaddr '192.168.1.1/24'
option ip6assign '60'

config interface 'lan2'
option proto 'dhcp'

wireless:

config wifi-device 'radio0'
option type 'mac80211'
option path 'platform/soc/20300000.mmcnr/mmc_host/mmc1/mmc1:0001/mmc1:0001:1'
option band '2g'
option channel '1'
option htmode 'HT20'

config wifi-iface 'wifinet1'
option device 'radio0'
option mode 'sta'
option network 'lan2'
option ssid 'W2.4'
option encryption 'psk2'
option key 'XXXXXXXXXXXXXXXX'

firewall:

# 189 lines of RPI Zero 23.12.3 unchanged default stuff. Not pasted, to prevent clutter...

config zone
option name 'lan2'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'ACCEPT'
list network 'lan2'

  • The only config part outside of the Zero was, to disable "isolate clients" on the access point.
  • I have HDMI connected to the Zero, to monitor it booting.
  • On first boot Once the HDMI log output no longer scrolls, i run "ifconfig" to find out its IP on the 192.168.4.x Wifi. From then it takes another ~15 seconds, until 192.168.4.x responds to SSH and browser requests of other WiFi clients.
  • Now unplugged everything from the Zero except the power cable
  • Same Wifi IP as before, SSH via Putty 0.83 took roughly 1 sec to connect, WinSCP 6.5.6 (over SCP) ~3 sec. Works with 2 different Windows 11 Wifi clients (1 think one is Broadcom, the other intel)

Let me know if you find weird config parts or want me to vary any config parts.

19

Thanks for all of that...

I just had a breakthrough...

On a whim, I brought the device downstairs and it suddenly worked. But it only worked once. When I rebooted the device, it failed again.

That got me thinking and then I decided to try locking the device to my downstairs AP. This seems to have actually fixed the issue, but has left me entirely stumped as to why. Since my infrastructure is based on Unifi (using the stock firmware), troubleshooting the issue is pretty much out of scope, but it's odd since there are very few differences between the two APs which I'll highlight for those curious.

  • Unifi based system with SSID configuration set identically for both APs; wifi client isolation is disabled
    • Core Switch: USW-Pro-24PoE
    • Attic Switch: USW-Flex
    • Upstairs AP: Unifi AP AC Pro
      • Qualcomm Atheros
      • 3x3 antenna system
      • Unifi firmware 6.8.2
      • 2.4G Channel 1, 20MHz
      • WPA2 encryption
      • Disabled: 802.11k/v/r and also 802.11w
      • Connects via Attic Switch > Core Switch
    • Downstairs AP: Unifi AP AC SHD
      • Qualcomm Atheros
      • 4x4 antenna system
      • Unifi firmware 6.8.2
      • 2.4G Channel 6, 40MHz
      • WPA2 encryption
      • Disabled: 802.11k/v/r and also 802.11w
      • Connects directly to the Core Switch

As you can see, there are very few differences between the APs, but ssh works when connected to the SHD and not the Pro.

What is even more odd, though, is that only ssh traffic that is problematic and it seems that is the case only from this Pi Zero device. Normally I would expect that if there was a connectivity issue, it would be more 'global' in nature.

For example:

  • Why am I able to reach the Pi Zero W's LuCI web interface without issue when it's connected to the Pro, but not ssh? (Both are TCP streams)
  • Why can I ssh from my Mac mini when it is connected to the Pro (I've disabled ethernet and verified it is connected to the Pro via wifi)? This suggests that there isn't some inherent issue with ssh via the connection path (although it was connecting at 5GHz, not 2.4)

It's really curious...

I may try spinning up OpenWrt on the Pi400 that I have around and see if that has similar issues (I can then test 2.4 vs 5G to see if that makes a difference, too).

20

forgot to mention my AP: flint 2