sergio/takana
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

la cuenta necesitaba sus LLAVES, no su contraseña

Browse Source 
El primer `ssh -i ~/.ssh/tawasuyu sergio@gioser.net -p 2345` dio «Permission denied (publickey)», y
era exacto: el sshd de la caja tiene `PasswordAuthentication no`, así que la clave sirve para `su` y
la consola, no para SSH. Faltaba `~/.ssh/authorized_keys`, que se creó vacío con la cuenta. Copiadas
las dos llaves de gioser (`tawasuyu` y `sergio@tatata`), entra — y `claude` abre en la misma sesión.

Dos detalles que hacen que se sienta como la máquina de siempre: `gioser.net` ya resuelve a la caja,
y la llave de host es LA MISMA que la de gioser (se copiaron en el cutover del gitea, §6.25),
comprobado: SHA256:ltSl+rgr2Uc… en las dos. Por eso no salta el aviso de «REMOTE HOST IDENTIFICATION
HAS CHANGED» al entrar al nombre de siempre.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
Sergio
2026-09-17 18:37:52 +00:00
co-authored by Claude Opus 5
parent a3e891a601
commit 8db55db465
1 changed files with 28 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/28-servidor-de-produccion.md
+28
View File
@@ -2912,6 +2912,34 @@ repo vive en `/opt/takana` ⇒ **el índice por ruta no coincide**. Se resuelve
directorio a `-opt-takana` o dándole al repo la misma ruta; hasta entonces el agente arranca sin su
memoria del proyecto aunque los 733 ficheros estén en disco.
### 6.50 bis 🔑 La cuenta necesitaba sus LLAVES, no su contraseña *(2026-09-17)*
Creada la cuenta, el primer intento del usuario falló:
```
$ ssh -i ~/.ssh/tawasuyu sergio@gioser.net -p 2345
sergio@gioser.net: Permission denied (publickey).
```
Y era exacto: **el `sshd` de la caja tiene `PasswordAuthentication no`**, así que la contraseña
`tawasuyu` sirve para `su` y para la consola, **no para entrar por SSH**. Lo que faltaba era su
`~/.ssh/authorized_keys`, que se creó vacío con la cuenta. Copiado el de gioser —dos llaves,
`tawasuyu` y `sergio@tatata`— entra:
```
$ ssh -i ~/.ssh/tawasuyu sergio@gioser.net -p 2345
ENTRA como sergio en takana · /home/sergio
$ claude -p "…" → ENTRÉ POR SSH Y ABRÍ CLAUDE
```
Dos detalles que hacen que esto se sienta como la máquina de siempre: **`gioser.net` ya resuelve a la
caja**, y **la llave de host es la MISMA que la de gioser** (se copiaron en el cutover del gitea,
§6.25) — comprobado: `SHA256:ltSl+rgr2Uc…` en las dos. Por eso no aparece el aviso rojo de
«REMOTE HOST IDENTIFICATION HAS CHANGED» al entrar al nombre de siempre.
⚠ El `sshd` escucha en **22022 y 2345**, los dos generales: `2345` es el puerto que los clones de
git ya usaban, y sirve igual para entrar.
### 6.51 🔥 Me dejé afuera de la caja — 20 minutos caída, y tres causas encadenadas *(2026-09-17)*
Crear una cuenta de usuario tiró el servidor de producción. Queda escrito entero porque **ninguna de