jaumeferré

Llevo un tiempo usando homepage como panel de inicio para llegar rápido a todos los servicios que tengo montados en casa: Proxmox, Home Assistant, el gestor de descargas, la galería de fotos, mis webs... todo en una sola página con sus iconos bien puestos.

El problema es que Homepage se configura con ficheros YAML, y a mí eso de escribir YAML en remoto, en la terminal, sin que nadie me avise si me dejo una coma o un espacio mal puesto, nunca me ha hecho especial ilusión. Cada vez que quería añadir un servicio nuevo era abrir un editor de texto por SSH, escribir con cuidado, guardar, recargar la página y cruzar los dedos.

Mi primera idea fue tirar la toalla con Homepage y probar otra cosa que se configurase con el ratón, arrastrando iconos. Monté un contenedor nuevo para probarlo en paralelo, sin tocar lo que ya tenía funcionando. Pero cuanto más lo pensaba, más cuenta me daba de que el problema real no era el propio Homepage, sino cómo lo estaba editando. Total, para once o doce servicios que no cambian cada semana, no merecía la pena renunciar a tener toda la configuración en texto plano, que puedo respaldar y llevar un historial de cambios sin ningún esfuerzo.

Así que cambié de idea: en vez de sustituir la herramienta, arreglé la forma de trabajar con ella.

La solución: abrir la carpeta remota como si fuera local

Resulta que mi editor favorito, Code - OSS, la versión de código abierto de Visual Studio Code, puede conectarse por SSH a cualquier máquina y abrir una carpeta de allí como si estuviera en mi propio ordenador. Edito, guardo, y el cambio ya está en el sitio correcto, sin copiar ficheros de un lado a otro ni pelearme con nano desde el móvil.

Tuve un pequeño tropiezo al principio: al usar la versión de código abierto del editor (sin marca de fábrica), la extensión "oficial" para esto no estaba disponible — solo funciona en la versión con todo el empaquetado de la empresa. Por suerte hay una alternativa hecha por la comunidad, open-remote-ssh, que hace exactamente lo mismo y sí está disponible para cualquiera.

1. Habilité la API propuesta

Abrí la paleta de comandos (Ctrl+Shift+P) y ejecuté Preferences: Configure Runtime Arguments. Se abrió ~/.vscode-oss/argv.json. Añadí la clave enable-proposed-api:

{
  "enable-proposed-api": ["jeanp413.open-remote-ssh"]
}

Guardé el fichero, respetando el resto de contenido que ya tenía el JSON — solo añadí esa clave.

2. Configuré el binario de servidor

Como code-oss no tiene binarios de servidor remoto propios, tuve que apuntar al de VSCodium (es compatible). Fui a Ctrl+, (Settings), busqué remote.SSH y edité directamente mi settings.json (Ctrl+Shift+P → Preferences: Open User Settings (JSON)) para añadir:

{
  "remote.SSH.serverBinaryName": "codium-server",
  "remote.SSH.serverDownloadUrlTemplate": "https://github.com/VSCodium/vscodium/releases/download/${version}/vscodium-reh-${os}-${arch}-${version}.tar.gz"
}

Lo cerré del todo (no basta con recargar ventana) y volví a abrirlo para que cargara el argv.json actualizado.

Cuatro líneas en total, nada del otro mundo, pero sin ellas la conexión se quedaba a medias intentando descargar algo que no existía.

3. Me hice un alias de terminal para abrirlo con un solo comando

Desde el equipo que iba a usar para code-oss, confirmé el nombre exacto de mi binario (en Arch/EndeavourOS suele ser code-oss, pero conviene comprobarlo):

which code-oss

Si no devuelve nada, prueba con:

which code

Descubrí que podía abrir directamente la carpeta de configuración remota con un único comando. El truco estaba en el formato del URI que usa la extensión:

vscode-remote://ssh-remote+<alias-ssh>/<ruta-remota>

Donde <alias-ssh> es el nombre que le puse al Host, y <ruta-remota> la ruta absoluta a la carpeta que quería abrir en esa máquina.

Con eso, el comando completo me quedó así:

code-oss --folder-uri "vscode-remote://ssh-remote+homepage-lxc/opt/homepage/config"

(sustituyendo homepage-lxc por mi alias SSH, /opt/homepage/config por la ruta real, y code-oss por el nombre exacto de mi binario)

Lo añadí como alias en mi ~/.bashrc:

alias homepage-edit='code-oss --folder-uri "vscode-remote://ssh-remote+homepage-lxc/opt/homepage/config"'

Y recargué el shell:

source ~/.bashrc

Desde entonces con solo escribir homepage-edit en cualquier terminal se abre directamente code-oss con la carpeta remota a editar, sin clics.

El pequeño detalle que casi me frena: la contraseña

Una vez conectado, cada vez que intentaba entrar me pedía la contraseña del contenedor. Y claro, eso rompe toda la comodidad — si tengo que teclear una contraseña cada vez, para eso sigo con la terminal de siempre.

La solución fue generar una llave de acceso en mi ordenador y decirle al contenedor "esta llave ya vale, no hace falta preguntar más". Una vez hecho eso, la conexión pasa directa, sin ningún aviso ni contraseña de por medio.

1. Comprobé si ya tenía una llave generada

Desde mi ordenador:

cat ~/.ssh/id_ed25519.pub

Ya tenía una llave (me devolvió una línea empezando por ssh-ed25519), así que pasé directo al paso 2. Si no hubiera tenido ninguna, la habría creado con:

ssh-keygen -t ed25519

(dejando todo por defecto, sin passphrase, para que la conexión sea 100% automática)

2. Inyecté la llave directamente en el contenedor

Aquí está el detalle que lo hace cómodo: no hace falta contraseña para este paso, porque Proxmox ya tiene acceso directo al contenedor a través de su propia API (pct exec), sin pasar por SSH. Así que desde el host Proxmox (no desde mi ordenador), ejecuté:

pct exec <CTID> -- bash -c "mkdir -p /root/.ssh && chmod 700 /root/.ssh && echo 'TU_CLAVE_PUBLICA_AQUI' >> /root/.ssh/authorized_keys && chmod 600 /root/.ssh/authorized_keys"

(sustituyendo <CTID> por el ID real de mi contenedor, y TU_CLAVE_PUBLICA_AQUI por el contenido que me había devuelto el cat del paso 1)

3. Comprobé que ya entraba sin preguntar nada

De vuelta en mi ordenador:

ssh root@mi-servidor

Entró directo, sin pedir contraseña. Resuelto.

Para que esto no se repita en cada contenedor nuevo: guardé mi clave pública en el propio host Proxmox, y ahora la añado automáticamente al crear cualquier LXC futuro:

pct create <CTID> local:vztmpl/debian-12-standard_12.7-1_amd64.tar.zst \
  --hostname mi-contenedor \
  ...(resto de opciones)... \
  --ssh-public-keys /root/.ssh/id_ordenador.pub

Así, cada contenedor nuevo nace ya con mi llave autorizada, sin tener que repetir este paso nunca más.

El resultado

Ahora, cuando quiero tocar algo del dashboard, abro directamente esa carpeta en mi editor. Veo si me falta algo o me sobra una coma antes de guardar, porque el propio editor me avisa. No hay terminal, no hay nano, no hay contraseñas. Y sigo teniendo toda la configuración en texto plano, así que si algún día meto la pata puedo ver exactamente qué cambié y deshacerlo.

A veces el problema no es la herramienta que usas, sino que nunca te has parado a pensar cómo la estás usando.

Eso sí, hubo que darle cuatro retoques a la configuración para que la extensión "engañara" bien al editor y descargara la pieza que le faltaba en el servidor remoto, en vez de buscar la versión de la empresa que no iba a encontrar. Nada del otro mundo, cuatro líneas sueltas en un fichero de ajustes, pero sin ellas la conexión se quedaba a medias.

Y para no tener que escribir la IP y el usuario cada vez que quería conectarme, le puse un alias a la máquina en la configuración de SSH de mi ordenador. Así, en vez de recordar una dirección, simplemente le digo al editor que se conecte a un nombre corto y él ya sabe a qué máquina y con qué usuario ir.

Con un par de ajustes extra (nada del otro mundo, cuatro líneas de configuración) quedó funcionando igual de bien.