Le di acceso SSH a un agente para revivir una laptop

Reviví otra laptop instalando NixOS. Esta vez ni toqué el teclado.

La primera vez fue a las patadas, yo solo

En abril reviví otra máquina con NixOS. Terminé en un shell de recovery sin ls ni mount, escribiendo paths del nix store a mano. Seis generaciones de sistema en un día, cada una una lección distinta, todo manual.

Esta vez era una ThinkPad T430s de 2012, batería al 0.5% de salud, que alguien iba a tirar. En vez de repetir el mismo camino a mano, le di acceso SSH a Claude y le pedí que hiciera todo: dejar entrar SSH en Windows, resolver lo que hiciera falta, particionar el disco, instalar NixOS. Yo solo hacía lo que necesitaba manos físicas - BIOS, orden de arranque, sacar y poner el USB.

Primero, que Windows deje entrar por SSH

Habilitar OpenSSH Server en Windows es lo fácil. La conexión llegaba, el host key se agregaba sin problema, pero el login fallaba:

ssh_askpass: exec(/usr/bin/ssh-askpass): No such file or directory
Permission denied, please try again.
Received disconnect ... Too many authentication failures

La cuenta no tenía contraseña configurada, así que no debería haber nada que rechazar. La causa real: Windows trae por defecto la política "Accounts: Limit local account use of blank passwords to console logon only", que bloquea el login con password vacía desde la red - y SSH cuenta como acceso remoto, sin importar que la cuenta sea local.

Pelear con esa política no vale la pena. El fix fue cambiar a autenticación por key. Para una cuenta admin (el caso común en una laptop personal), Windows OpenSSH no usa el authorized_keys del usuario - usa C:\ProgramData\ssh\administrators_authorized_keys, con ACL restringida solo a SYSTEM y Administrators.

El wifi decía "Hardware Desactivado" y no era el wifi

Con SSH andando, tocaba resolver el wifi:

Estado de radio: Hardware Desactivado
                 Software Desactivado

El sospechoso obvio era el driver de la tarjeta. Pero el adaptador real - un Intel Centrino Ultimate-N 6300 AGN - figuraba en Device Manager con Status: OK. Su driver estaba perfecto. El culpable era otro dispositivo completamente distinto: ACPI\LEN0078, sin nombre visible en la lista, con Status: Error / Problem: CM_PROB_FAILED_INSTALL.

Ese hardware ID corresponde al Lenovo HID Mini-driver for Hardware Radio Switch - el driver que interpreta Fn+F5 y el switch físico, y controla el estado real del radio. Sin él, el switch no hace nada: el sistema no puede ni leer ni cambiar el estado, y el radio queda enclavado en "Desactivado". No era un problema de wifi. Era un problema del control del wifi.

Instalar dos paquetes Lenovo (Power Management, DS539638, y HID HW Radio, DS032422, específico para T430s) resolvió los dos lados, software y hardware.

El BIOS que no escucha F12

Antes de meter el USB de NixOS, otro obstáculo: con Windows Fast Startup activo, el POST pasa tan rápido que F12 no registra - arranca directo a Windows. Hay que apretar Enter una vez apenas aparece el logo para interrumpir el arranque; recién ahí F12 (o F1 para Setup) queda activo.

Y dentro del setup, el ítem que dice "Network Boot" no es el orden de arranque real - es solo qué dispositivo usar si se invoca boot por red (PXE). El Boot Priority Order real vive en otro submenú, con una lista numerada de 1 a 11. Para reordenar, la tecla que el menú indica ("+"/"-") no respondía por un mismatch de layout de teclado - la alternativa que sí funciona es F5/F6.

Ya en el instalador de NixOS, el home era de root

Con la ISO live arriba, escribir la clave SSH fallaba:

bash: line 1: /home/nixos/.ssh/authorized_keys: Permission denied

El comando estaba bien escrito. El directorio /home/nixos/.ssh ya existía, pero creado como root:root - el usuario nixos podía leerlo, no escribir. El fix, con el sudo sin password que trae la ISO:

sudo chown -R nixos:users /home/nixos/.ssh
mkdir -p ~/.ssh && echo "ssh-ed25519 ..." >> ~/.ssh/authorized_keys
chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys

nixos-install termina bien. El reboot, no

nixos-install reportó installation finished!, exit 0. umount -R /mnt && reboot. El sistema no arrancó el disco recién instalado - volvió a levantar el mismo instalador live. El Boot Priority Order seguía apuntando al USB, configurado así a propósito para el primer arranque, y nadie lo había revertido antes del reboot final.

Ahí vino el error que cometimos los dos: como "la instalación ya había terminado", sacamos el USB físicamente pensando que ya no hacía falta. Pero el sistema live seguía corriendo desde ese mismo USB. Perdió su backing store en caliente:

I/O error, dev loop0, sector 83872 op 0x0:(READ) ...
SQUASHFS error: Failed to read block 0x28f40e4: -5

La consola dejó de responder. Apagado forzado, reentrar al BIOS con el USB ya afuera, subir el bootloader nuevo ("Linux Boot Manager") a la posición 1 del Boot Priority Order. Recién ahí arrancó lo que habíamos instalado.

Otra vez sin wifi - pero por una razón completamente distinta

Ya en NixOS, el wifi volvió a fallar. Mismo síntoma en apariencia, causa nada que ver con la de Windows:

0: phy0: Wireless LAN
	Soft blocked: no
	Hard blocked: yes

iwlwifi cargado, wlp3s0 presente, NetworkManager habilitado, rfkill unblock all sin efecto. "Hard blocked" es el switch físico del borde de la laptop, no un bloqueo de software - nada que un comando resuelva. El fix fue mover el switch con la mano.

Dos veces sin wifi en la misma laptop, dos causas sin relación entre sí: un driver ACPI faltante de un lado, un switch físico del otro.

Dónde quedó el límite

El agente no necesitó adivinar nada de esto por su cuenta - siguió el mismo camino que hubiera seguido yo, solo que más rápido y sin cansarse a la tercera vuelta de diagnóstico. Encontró en minutos el ACPI\LEN0078, la política de blank passwords, el directorio root:root - cosas que a mí me hubieran tomado horas de ida y vuelta.

El único error real de la sesión lo cometimos los dos, y fue el más simple de todos: sacar un USB sin confirmar antes qué sistema estaba efectivamente corriendo. El agente ejecuta rápido y encuentra lo que a mí se me pasa. Pero verificar antes de un paso irreversible - antes de sacar el medio, antes de reformatear, antes de cualquier cosa que no tiene deshacer - sigue siendo mi trabajo, no el suyo.