Root por DID: SSH sin puertos, sin passwords y con recibo firmado — la demo de XionIA
276 segundos de shell de root sobre un t煤nel P2P directo. La llave naci贸 con la sesi贸n y muri贸 con ella. Seis registros firmados Ed25519 — incluidos los intentos fallidos.
$ tldr
Hoy abrimos una sesi贸n SSH de root en un host remoto sin abrir un puerto, sin password y sin ning煤n .pem que robar. La identidad fue un DID (par de claves Ed25519, no una cuenta de usuario), el transporte fue la sesi贸n cifrada de par a par que ya exist铆a entre los dos nodos, y la autorizaci贸n fue expl铆cita: el due帽o del host habilit贸 nuestro DID en un cat谩logo firmado — y lo revoc贸 despu茅s, con el rechazo dejando recibo. La sesi贸n dur贸 4m36s, movi贸 61.6 KB, y al cerrar no qued贸 nada: ni procesos hu茅rfanos, ni credenciales. Todo el episodio — sesi贸n exitosa, dos intentos fallidos y un rechazo administrativo — qued贸 registrado y firmado: 6 registros, todas las firmas verificables.
01La lecci贸n que dej贸 el robo m谩s grande de la historia
Hace una semana desarmamos el robo de US$ 6.360 millones a Binance: ninguna primitiva criptogr谩fica fall贸 — fall贸 el modelo de confianza. La autoridad para mover miles de millones estaba a un salto de una laptop, la identidad era la posici贸n de red, y las firmas leg铆timas eran el arma. Cuatro principios quedaron escritos con fuego: la identidad no es la posici贸n de red, cero rutas de firma de un solo salto, el descubrimiento no debe ser autoridad y los hosts son potencialmente hostiles.
Esta nota es la otra mitad de esa conversaci贸n: qu茅 se ve cuando esos principios se toman en serio en el acceso administrativo a un host. Spoiler: se ve un comando, tres puertas y un recibo firmado.
02Qu茅 se construy贸: tres puertas, cero parafernalia
El proyecto XionIA tiene un kernel P2P con identidad soberana por DID, transporte Noise de extremo a extremo y atravesamiento NAT sin abrir puertos. El nuevo comando remote monta sobre eso la capa que faltaba: shell administrativa real de otro host — OpenSSH de stock, sin parchear, con identidad y autorizaci贸n del kernel.
Lo que NO sobrevivi贸 al dise帽o
- Puertos: el sshd de sesi贸n no escucha en ninguna interfaz (sirve una conexi贸n por stdin/stdout, enganchado al t煤nel)
- Passwords y .pem: la clave Ed25519 se genera en memoria y muere con la sesi贸n — no hay credencial que robar despu茅s
- Relay: la sesi贸n administrativa viaja solo por el canal directo entre los dos kernels, jam谩s por un tercero
- Autorizaci贸n heredada de la red: estar "adentro" no te da nada
Lo que s铆 hay
- Puerta 1 · ACL del nodo — qui茅n puede hablar (la misma lista del chat)
- Puerta 2 · Cat谩logo ROOT_ADMIN — qui茅n puede tocar el host: apagado por defecto, DID por DID, firmado por el due帽o
- Puerta 3 · Clave ef铆mera — por cu谩nto: una llave nueva por sesi贸n, muerta con la sesi贸n
- Recibo Ed25519 de cada sesi贸n y de cada intento — incluidos los rechazos
03La demo, con n煤meros reales
Dos nodos reales: una consola linux/amd64 y un ARM (Raspberry con Arch), cada uno con su DID, ambos detr谩s de redes dom茅sticas, presentados por el faro del proyecto y conectados directo.
# en el host objetivo, el due帽o habilita — sin esto no funciona nada:
$ remote allow xeon
✅ ROOT_ADMIN habilitado para xeon — cat谩logo re-firmado
# en el iniciador (un usuario sin privilegios, nada m谩s):
$ remote jubilarte root
馃暢 abriendo t煤nel SSH hacia jubilarte (solo directo, jam谩s relay)...
✅ T煤nel listo — el nodo remoto ejecut贸 su openssh de sesi贸n (puerto local 35563).
Clave ef铆mera SHA256:Gkb1gmbD… · host de sesi贸n SHA256:fcAVmc9H…
# y dentro:
[root@alarm ~]# whoami
root
[root@alarm ~]# curl ifconfig.me ← egress real por la ruta normal
190.220.45.26
exit cerr贸 la sesi贸n, el t煤nel y la llave — todo junto. Lo que dejaron los dos extremos:
Y la parte que casi ning煤n producto puede mostrar: los fracasos tambi茅n dejaron recibo. Dos intentos previos quedaron en el registro firmado con su duraci贸n (0 s), su tr谩fico (~3 KB de handshake) y la huella de la clave de cada uno. Tras revocar la autorizaci贸n, el reintento fue rechazado (NOT_ADMIN) con un t煤nel de 0 bytes — y ese rechazo tambi茅n qued贸 firmado. No existe sesi贸n ni intento sin recibo.
04Auditor铆a sin curiosidad
Los metadatos est谩n auditados; el contenido no est谩 expuesto al auditor. Esa doble muralla es la diferencia entre un log que un compliance officer firma y una promesa que un compliance officer desconf铆a. Y la contabilidad cierra de ambos lados: los 61.6 KB est谩n firmados en el nodo que entr贸 y en el nodo que recibi贸, espejados.
05Lo que esto NO es (honestidad por delante)
El t煤nel ip:puerto arbitrario est谩 prohibido por dise帽o. Alcanzar otras m谩quinas de la LAN del nodo se har谩 solo por alias autorizados, sin revelar IPs.
El test publicado cubre dos nodos reales con camino directo. El doble NAT restrictivo de ambos lados est谩 en la cola de pruebas de campo del proyecto.
ROOT_ADMIN habilita la capa host completa, DID por DID. La granularidad (jaula / host / basti贸n por alias) es el siguiente escal贸n del cat谩logo.
Es la capa de comunicaci贸n autenticada y autorizaci贸n verificable — el cuello de botella que el robo a Binance mostr贸, no la b贸veda.
06Cierre
El acceso administrativo tradicional acumula d茅cadas de deuda: passwords reutilizados, .pem en repositorios, IPs expuestas, jump-hosts cuya seguridad es un VPN client desactualizado. La alternativa demostrada hoy no pide credenciales: pide identidad. El due帽o autoriza un DID, la sesi贸n nace y muere con su llave, y todo el episodio queda firmado — rechazos incluidos.
Fernando L贸pez (Mamanga) — Proyecto XionIA, Corrientes, Argentina.
Datos: transcripci贸n del test interno del 6/11/2026 entre dos nodos reales del proyecto (captura-test.txt), xionia-kernel v9.2 · DerinKuyu-SSH. Sobre el robo a Binance: an谩lisis on-chain de TRM Labs y confirmaciones p煤blicas (29–31/10/2026).
