SSH to OpenWrt/ImmortalWrt stalls at "Authenticating" (TCP + handshake succeed)

[NikulausRui]

Description

I can't connect to my openwrt by ssh, but use mac's terminal can work, my openwrt version is immortalWrt

Steps to Reproduce

1. Go to '...'
2. Click on '...'
3. Scroll down to '...'
4. See error

Expected Behavior

A clear and concise description of what you expected to happen.

Screenshots / Video

Environment Info

Please tell us what device you are using so we can reproduce the bug.

• OS: [macOS Sonoma]
• App Version: [v0.14.1]

Additional context
Add any other context about the problem here.

[kipavy]

Thanks for the report — and especially for the recording, which turned out to contain the most useful clue.

This isn't a connection failure. Stepping through the frames, the progress panel gets to:

• ✅ TCP connection 192.168.1.2:22
• ✅ SSH handshake — negotiating encryption
• ⏳ Authenticating as root ← it stops here
• ⬜ Opening shell — never reached

So TCP and key exchange both succeed against your router; it stalls during authentication. One frame also shows a session that did open (green, 14ms) with an empty terminal. I've retitled it accordingly.

What I've changed already

OpenWrt/ImmortalWrt uses dropbear, so I tested Voltius' SSH stack against dropbear 2018.76, 2019.78, 2022.82 and 2024.85 locally.

That found a real bug: Voltius always requested rsa-sha2-256 for public-key auth. dropbear before 2020.79 only supports ssh-rsa, so an RSA key your router accepts was rejected. Voltius now takes the signature algorithm from what the server advertises (server-sig-algs), and falls back to ssh-rsa for servers that advertise nothing. Confirmed: fails on dropbear 2018.76 before the fix, succeeds after; no change on modern servers.

I also bounded the authentication step. It had no timeout, which is why you got an endless spinner instead of an error — that alone made this much harder to diagnose than it should have been. It now fails with a message naming the likely cause.

What I could not reproduce

I could not reproduce the stall itself. Across all four dropbear versions — password, Ed25519 and RSA keys, with and without background connection churn — auth either succeeded in ~45ms or failed immediately. So I don't yet know whether the RSA fix addresses your case specifically, and I'd rather say that than guess.

What would settle it

1. How do you authenticate to this host — password, or a key? If a key, which type (ssh-keygen -l -f <keyfile>)?
2. Your dropbear version: ssh root@192.168.1.2 'dropbear -V' from Terminal (it prints to stderr), or ubus call system board.
3. Does enabling Legacy algorithms on the host (edit host → advanced) change anything?
4. Anything in the router's log while a connection is attempted: logread | tail -50.

The recording shows several other hosts on the same LAN working, so this is something specific to this router — those four answers should pin it down.

[NikulausRui]

@kipavy Thank you for your reply.

1. I authenticate to this host by password
2. Dropbear version is v2025.89
3. I have not enabled any advanced setting
4. Tue Aug 4 08:53:49 2026 authpriv.info dropbear[1374]: Child connection from 192.168.1.40:64441
   Tue Aug 4 08:53:49 2026 authpriv.info dropbear[1374]: Exit before auth from <192.168.1.40:64441>: Exited normally
   Tue Aug 4 08:53:49 2026 authpriv.warn dispatcher.uc: luci: failed login on / for admin from 112.96.83.87
   Tue Aug 4 08:53:49 2026 authpriv.warn dispatcher.uc: luci: failed login on / for admin from 112.96.83.87
   Tue Aug 4 08:53:50 2026 authpriv.warn dispatcher.uc: luci: failed login on / for root from 112.96.83.87
   Tue Aug 4 08:53:50 2026 authpriv.warn dispatcher.uc: luci: failed login on / for root from 112.96.83.87
   Tue Aug 4 08:53:50 2026 authpriv.warn dispatcher.uc: luci: failed login on / for root from 112.96.83.87

[kipavy]

Thanks — that's exactly what I needed, and it moves the diagnosis somewhere new.

What your answers rule out

dropbear 2025.89 with password auth means neither of the two fixes I shipped applies to you: the rsa-sha2 bug only affects dropbear < 2020.79 and only public-key auth. I re-tested password auth against dropbear 2025.88 (the newest I can get in a container) to be sure — connect + key exchange in 52ms, password auth in 44ms, no stall. So I'm back to not having an explanation, and I'd rather say so than pretend the earlier fix covers you.

What's in your log

Two things stand out.

1. Child connection from 192.168.1.40 … Exit before auth: Exited normally — that's Voltius itself.

The Reachability check (the status dot + latency on each host card) opens a plain TCP connection to port 22 and drops it immediately, once per host on a timer. Every one of those forks a dropbear child and produces exactly that log line. On 0.14.1 that ran every 10s per host, every 2s while a session is open, with no jitter — and it's already tracked as #90, where it was measured tripping a host-side rate limiter (ufw limit) and locking the user out of their own server. A busy router is a much more plausible victim of that than a Linux box.

This is the experiment I'd most like you to run: Settings → Hosts → Connectivity → turn Reachability check off (it can also be disabled per host in that host's settings), then try connecting. If the stall disappears, we have our answer. The rate-limiting fix — 60s/5s defaults, jittered, with hard floors — is on dev but not yet in a release.

2. Your router is being brute-forced from the internet.

failed login on / for admin/root from 112.96.83.87 is a WAN address hammering LuCI. If dropbear is exposed on the WAN too, its unauthenticated-connection slots are being consumed by that, which is a second way a LAN connection can end up waiting. Worth closing off regardless of this bug.

Two things that would settle it

1. Update to v0.15.1 (released yesterday). It bounds authentication at 30s, so instead of an endless spinner you'll get an error naming the likely cause — please paste that text verbatim.
2. logread -f running while you reproduce it. The 50-line tail you sent contains no authentication line at all — no auth succeeded, no bad password — so it doesn't cover the attempt that hung. What dropbear logs for the connection that actually stalls is the missing piece.

Also: is it 100% reproducible, or intermittent?

[kipavy]

v0.16.0 is out, and it contains the fix for the thing I suspect is hitting you.

The reachability probe that was forking a dropbear child every few seconds — the Child connection from 192.168.1.40 … Exit before auth lines in your log — now runs from a single scheduler: 60s idle instead of 10s, 5s while a session is open instead of 2s, jittered, deduplicated per host:port, with hard floors so it can't be configured back down into the range that caused this. Where I could measure it against a rate-limiting firewall, it went from 31 blocks to none.

So the experiment is easier than the one I asked for last time — you shouldn't need to turn anything off:

1. Update to v0.16.0 and try connecting normally.
2. If it still stalls, the 30s auth bound from 0.15.1 means you'll now get an error naming a cause rather than an endless spinner — please paste that text verbatim.
3. If you can, logread -f while you reproduce it. Your earlier 50-line tail contained no authentication line at all, so it missed the attempt that hung; what dropbear logs for the stalling connection is still the missing piece.

And the earlier question still stands: is it reproducible every time, or intermittent?

If it's fixed, say so and I'll close this — no need to write anything up.

[NikulausRui]

@kipavy I have update to the version v1.17.1 and still have same issue. Below is the output of "logread -f"

Thu Aug 6 10:14:25 2026 authpriv.info dropbear[22881]: Child connection from 192.168.1.39:64400
Thu Aug 6 10:14:25 2026 authpriv.notice dropbear[22881]: Password auth succeeded for 'root' from 192.168.1.39:64400
Thu Aug 6 10:14:25 2026 authpriv.info dropbear[22881]: Exit (root) from <192.168.1.39:64400>: String too long
Thu Aug 6 10:14:27 2026 authpriv.info dropbear[22885]: Child connection from 192.168.1.39:64401
Thu Aug 6 10:14:27 2026 authpriv.notice dropbear[22885]: Password auth succeeded for 'root' from 192.168.1.39:64401
Thu Aug 6 10:14:27 2026 authpriv.info dropbear[22885]: Exit (root) from <192.168.1.39:64401>: Exited normally