Avalon 1346 – SSH Access Unreachable

Hard power-cycle the controller for 30 seconds at the PSU switch or PDU port — not a soft reboot from the web UI. Wait the full 30 s, power back on, give the miner 90 s to boot, then re-test `nc -vz <miner-ip> 22`. Restarts the `dropbear` daemon if it was wedged. Solves the single-process-crash case in roughly 40% of bench tickets we see on this error.

Log into the web UI on `http://<miner-ip>` with default credentials `root / root` (retail `MM314x` firmware). Navigate System → Miner Configuration (or System → Remote Access on newer builds). Find the `SSH Enable` / `SSH Service` / `Remote Shell` toggle. Turn it on. Save. Reboot from the web UI. Wait 90 s post-reboot, then re-test SSH. Newer retail Avalon firmware ships SSH off by default — this is the fix in most post-2023 unit cases.

On first successful SSH login, your very first command is `passwd`. Default seed credentials are `root / avalon` — rotate to a real password immediately. A controller reachable on any network you don't fully control with default creds is a botnet node waiting to happen. Mining Hacker hygiene rule, no exceptions.

On the web UI status page, copy the exact MM firmware string (e.g. `MM3142_AvalonHome_25011002`). Cross-reference https://avalonminer.org/firmware-document/ for known-good builds. Some `MM3141_*` early-2024 builds had a `dropbear` startup race that the `MM3142_*` series fixed — schedule an update during your next maintenance window if you're on a flagged build.

Confirm port 22 isn't being blocked by your network gear. Some prosumer routers (Ubiquiti EdgeRouter, MikroTik, OPNsense) block inbound SSH by default. SSH from a workstation on the same L2 broadcast domain as the miner — bypass the router. If SSH works on-LAN but fails through a management VLAN, the issue is your firewall, not the miner.

Run a port scan to confirm exactly which services are alive: `nmap -p 22,23,80,443,4028,8000,8080 <miner-ip>`. Healthy 1346 with SSH disabled: `22 closed, 80 open, 4028 open`. Daemon-crashed: `22 refused, 80 open, 4028 open`. Network-fault: most ports `filtered`. Use the result to confirm which diagnostic bucket you're in before escalating to firmware re-flash.

Factory reset via the web UI: System → Maintenance → Restore Factory Defaults (location varies by firmware revision). Wipes `/config/`, regenerates default credentials, and re-enables SSH on most retail firmware images. Save your pool URLs and worker names *before* hitting reset — you'll re-enter them post-reset. Reboot, wait 2 minutes (factory reset takes longer than a normal boot), retry SSH.

Factory reset via the hardware reset button when the web UI is also dead: with the miner powered on and idle, press and hold the controller's reset button for 10 seconds until the LED pattern changes. Release. Miner reboots into factory state. The button is a small recessed pinhole next to the network port — use a paperclip, not a screwdriver tip (you'll bend the switch).

Re-flash stock retail firmware via the web UI upload page. Download the matching `MM314x_AvalonHome_*.tar.gz` from https://avalonminer.org/firmware-document/. Upload via Web UI → System → Firmware Update. Do NOT power-cycle during the flash (5–8 minutes). Post-flash, factory reset to clear residual config, then verify SSH responds on `tcp/22`.

Sanity-check the controller's date/time. Some `dropbear` builds on Canaan firmware refuse to start if the RTC is wildly off (default RTC on a fresh 1346 is often `2014-01-01` until NTP syncs). Confirm web UI shows current date/time. If not, set NTP server explicitly (`pool.ntp.org` or a Canadian regional pool like `ca.pool.ntp.org`), reboot, retest SSH.

UART/serial console rescue when web UI and SSH are both dead. The MM controller exposes a 3.3 V UART header on the PCB (typically `J5` near the SoC, 4 pins: GND, TX, RX, optional VCC). Connect a USB→UART adapter (FTDI FT232RL or CP2102) at `115200 baud, 8N1`. Watch the boot log. From U-Boot prompt you can interrupt boot and inspect the rootfs. Single most powerful diagnostic on a bricked-management 1346.

From the U-Boot prompt, boot into single-user mode: `set bootargs ${bootargs} init=/bin/sh; boot`. Mount the rootfs read-write. Inspect `/etc/init.d/` for an `S60dropbear` startup script and `/usr/sbin/dropbear` binary. Missing init script *and* binary = firmware was built without SSH; only fix is re-flashing a stock image. Both present = manually invoke `/etc/init.d/S60dropbear start` to confirm the daemon binary works.

From single-user shell: `grep -i ssh /config/system.conf`. If you see `ssh_enable=0`, set it to `1`, save the file, reboot. Same setting the web UI toggle controls — useful when the web UI is also broken or the toggle is hidden under a menu the GUI build doesn't expose.

Re-generate corrupted SSH host keys when `dropbear` starts but disconnects clients immediately. From single-user shell: `rm /etc/dropbear/dropbear_*_host_key`. On next `dropbear` start, the daemon regenerates fresh keys. Caveat: your SSH client will warn about a changed host key — clear the offending entry from your local `~/.ssh/known_hosts` so you can reconnect.

If your firmware is a hardened/institutional build with SSH stripped entirely, flash a stock retail MM image from https://avalonminer.org/firmware-document/. Match the major MM line of your current firmware (`MM314 → MM314`). Do NOT cross major MM lines without confirming compatibility — `MM314 → MM312` will brick. DCENT_OS is on D-Central's roadmap for Canaan / Avalon hardware but is NOT yet available; stick with stock Canaan retail MM firmware on the 1346 today.

Stop DIY when: stock firmware re-flashed and SSH still dead; UART console shows kernel panic at boot or repeated `eMMC read error`; the 1346 ARP's on the switch but no IP responds for any port (controller's network stack is dead, not just SSH); two different MM firmware versions both fail to bring SSH up. You're in MM controller replacement territory — book a D-Central ASIC Repair slot.

D-Central bench process for SSH-unreachable 1346 controllers: bench-test the MM controller against a known-good 1346 chassis (isolates controller fault vs. backplane fault). If controller is the fault, replace MM board with a graded-equivalent unit, flash latest stable retail MM firmware, re-pair with the chassis's hashboards, run a 24-hour burn-in confirming SSH, web UI, and cgminer API stay stable. If chassis is the fault, replace backplane and retest with the original MM controller.

Ship safely. Pack the MM controller in an anti-static bag with desiccant, double-box with at least 5 cm foam on every side. If shipping the full miner, brace the hashboards with foam blocks — the 1346 chassis has long unsupported hashboard rails that crack in shipping if not braced. Include a note with: observed symptoms, exact MM firmware version, what diagnostic steps you tried, and your contact info. Saves us bench time, saves you repair cost.