Claude para sysadmins: 6 tareas de servidor diarias

Claude para administradores de sistemas: primero el asesoramiento y después la ejecución

Claude funciona mejor como revisor para los administradores de sistemas. Pegue un fragmento de registro, un archivo de configuración, un comando que no reconoce o una cadena de error, y recibirá una explicación que puede comprobar antes de cambiar nada en el equipo. Una respuesta incorrecta no le cuesta nada hasta que la ejecuta. Por eso, mantener el modelo en el lado del asesoramiento es la base de seguridad.

Cada semana se repiten seis tareas en un VPS Linux alquilado (servidor privado virtual). Cada una de ellas incluye un patrón de solicitud que funciona, el comando que demuestra la respuesta y el modo de fallo que debe esperar. Ninguna requiere que el modelo tenga acceso a su servidor. Puede pegar contenido desde una pestaña del navegador o desde una ventana de su propio escritorio, ya que Claude se ejecuta de forma nativa en Linux como aplicación de escritorio y CLI.

El orden importa en un equipo de producción: lea la explicación, ejecute la comprobación usted mismo y después decida. La autonomía es adecuada en una VM de pruebas. En el equipo que presta servicio a sus clientes, es preferible revisar, porque el modelo no puede ver el estado sobre el que está haciendo suposiciones.

Lo que nunca debe pegar

Todo lo incluido en el prompt sale de su servidor. Estas cuatro categorías deben permanecer en el servidor:

• Claves privadas: ~/.ssh/id_ed25519, /etc/ssh/ssh_host_*_key y cualquier clave TLS (seguridad de la capa de transporte) en /etc/letsencrypt/live/.
• Archivos de credenciales: .env, ~/.aws/credentials, /root/.docker/config.json y contraseñas de bases de datos en cualquier archivo o línea de registro.
• Datos de cuentas: /etc/shadow y /etc/gshadow. Ninguna pregunta de administración de sistemas necesita un hash de contraseña para responderla.
• Cualquier dato perteneciente a sus usuarios: direcciones de correo electrónico, filas de pedidos, registros de solicitudes que contengan cookies de sesión o PII (información de identificación personal).

Las claves públicas se pueden pegar. Las claves privadas no. Además, ambos archivos parecen similares a simple vista, así que lea la primera línea antes de copiar: un archivo cuya primera línea contiene BEGIN OPENSSH PRIVATE KEY nunca debe incluirse en un prompt. Distinguir correctamente el material de sus claves SSH merece diez minutos por sí solo.

Redacte la información antes de pegarla, en lugar de confiar en que detectará un token entre 200 líneas:

sudo journalctl -u myapp -n 200 --no-pager | sed -E 's/(token|secret|password|api[_-]?key)[=:][^[:space:]]+/\1=REDACTED/gI'

Docker tiene una trampa específica. docker compose config interpola los valores de .env en la salida que muestra, por lo que esa salida es un secreto aunque el archivo del disco no lo fuera. Use docker compose config -q, que valida y no muestra nada. Para consultar la política general sobre lo que un agente puede ver, mantener los secretos fuera de los agentes de IA explica la parte relacionada con el entorno.

Tarea 1: ¿por qué falló este servicio?

Empiece con los dos comandos que contienen la respuesta:

systemctl status myapp.service --no-pager
sudo journalctl -u myapp.service -b -n 100 --no-pager -o short-iso

Incluya ambos, junto con el contexto que el modelo no puede deducir: la distribución y la versión, el último cambio que hizo, si el servicio funcionó alguna vez y cuánto tiempo ha pasado desde que falló. Pida primero el mecanismo.

Ubuntu 24.04. myapp.service funcionaba correctamente hasta que edité la unidad hace una hora. Aquí están systemctl status y las últimas 100 líneas del journal. ¿Qué línea es el primer error real y qué significa? Todavía no indique ninguna solución.

«Todavía no indique ninguna solución» cumple una función importante en esa solicitud. Los registros ocultan el primer fallo entre los reintentos que este provoca, por lo que un modelo al que se le pide una solución explicará la última línea que encuentre. La línea importante suele estar veinte líneas por encima del ruido.

El resultado puede ser una línea como Main PID: 1841 (code=exited, status=203/EXEC). El estado de salida 203/EXEC significa que el kernel no pudo ejecutar el archivo indicado en ExecStart: la ruta no existe o el archivo existe pero no tiene permisos de ejecución. Una línea #! que indique un intérprete no instalado produce el mismo estado. Todo esto se puede comprobar con ls -l y head -1.

Modo de fallo: una causa inventada. Si incluye muy poco contenido, el modelo completará la información que falta con algo genérico, como «el puerto ya está en uso». La forma de corregirlo es hacer una pregunta adicional: «¿Qué línea de lo que le he proporcionado respalda esa afirmación?». Una causa que nadie puede señalar en el texto es una suposición.

Trabajo 2: redactar una unidad de systemd o una entrada de cron

Proporciónele los datos que necesita un archivo de unidad: el comando exacto, el usuario con el que se ejecuta, el directorio de trabajo, si debe esperar a la red y qué debe ocurrir cuando termina con un código distinto de cero. Después, verifique el resultado antes de habilitar nada.

sudo systemd-analyze verify /etc/systemd/system/myapp.service
sudo systemctl daemon-reload
sudo systemctl start myapp.service
systemctl status myapp.service --no-pager

systemd-analyze verify analiza el archivo igual que systemd, por lo que detecta errores que pasan desapercibidos a simple vista. Una directiva mal escrita muestra /etc/systemd/system/myapp.service:7: Unknown key name 'Enviroment' in section 'Service', ignoring.. Un binario inexistente muestra Command /usr/local/bin/myapp is not executable: No such file or directory. Ambos permanecen silenciosos durante daemon-reload. Por eso una unidad puede cargarse correctamente y fallar en cuanto se ejecuta.

Hay dos errores de redacción que se repiten. El primero es After=network.target, que sólo indica que la pila de red está configurada, no que ya exista una dirección. Un servicio que se enlaza a una IP concreta falla durante el arranque con bind: Cannot assign requested address. La solución es Wants=network-online.target junto con After=network-online.target. El segundo es Type=simple para un programa que se ejecuta como daemon: systemd considera que el primer proceso es el servicio, el proceso padre termina de inmediato y la unidad se marca como detenida mientras el proceso real continúa sin supervisión. Es el error que un modelo tiene más probabilidades de entregarle, porque no puede saber por el comando si el binario crea un proceso hijo. Por eso conviene saber qué garantiza cada valor de Type= a systemd antes de aceptar el borrador.

Para una programación, compruébela en lugar de leerla:

systemd-analyze calendar 'Mon *-*-* 04:00:00'

Esto muestra la forma normalizada y la próxima hora en que se ejecutará la expresión. Así se resuelve cualquier duda sobre su significado. Si está eligiendo entre un timer y un crontab, los servicios y timers de systemd en un VPS explican las diferencias.

Cron tiene una trampa sobre la que ningún modelo le advertirá si no se lo pide. Cron ejecuta los trabajos con un entorno mínimo. Por eso PATH equivale aproximadamente a /usr/bin:/bin y nunca se lee el perfil del shell. Un trabajo que funciona al pegarlo en el terminal falla bajo cron con /bin/sh: 1: docker: not found, porque ese binario se encuentra en /usr/local/bin. Use rutas absolutas en los crontabs. Si la exigencia de un archivo de unidad de especificar el usuario, el entorno y las dependencias le parece una formalidad frente a una sola línea de crontab, los problemas que systemd se diseñó para resolver explican el origen de esa verbosidad.

Trabajo 3: revisar un archivo de nginx o Compose antes de ponerlo en producción

Este trabajo ofrece el mejor rendimiento. Pegue el archivo, indique qué debería hacer y pida una explicación línea por línea de lo que hace realmente.

Este vhost debería servir example.com mediante HTTPS y enviar /api a un servicio local en el puerto 8080. Léamelo y señale cualquier aspecto que no coincida con esa descripción.

Después, ejecute la herramienta que conoce la sintaxis:

sudo nginx -t
docker compose config -q

nginx -t muestra nginx: configuration file /etc/nginx/nginx.conf test is successful o indica el archivo y la línea, como en nginx: [emerg] unknown directive "proxy_pas" in /etc/nginx/conf.d/app.conf:12. docker compose config -q no muestra nada cuando el archivo se analiza correctamente y muestra algo directo, como yaml: line 7: did not find expected key, cuando la indentación es incorrecta.

Ninguna de las dos herramientas comprueba la intención. Una configuración que supera nginx -t todavía puede enviar las peticiones al puerto equivocado o escuchar en 0.0.0.0 cuando necesitaba 127.0.0.1. Esa diferencia es donde el modelo resulta útil, pero también donde falla: si se le pide corregir una directiva, suele devolver el archivo completo reescrito y omitir silenciosamente dos de sus directivas. Pida las líneas modificadas y el motivo de cada cambio. Después, edite el archivo manualmente.

Confirme qué expuso realmente:

sudo ss -tulpn

Sin sudo puede ver los sockets en escucha, pero no los procesos que los poseen. Si esa salida le sorprende, qué son los puertos y cómo los asocia Linux es una explicación más breve.

Trabajo 4: explique un comando desconocido antes de ejecutarlo

Pegue el comando y hágale cuatro preguntas: qué hace cada indicador, qué escribe, qué elimina y qué ocurre si lo ejecuto dos veces. La última pregunta detecta más daños que las demás.

Considere find /var/log -name '*.gz' -mtime +7 -delete. Una buena respuesta indica que -mtime +7 cuenta períodos completos de 24 horas y descarta la fracción, por lo que coincide con archivos de al menos ocho días de antigüedad, no siete. También indica que find evalúa su expresión de izquierda a derecha, por lo que colocar -delete delante de -name elimina todo lo que haya bajo la ruta inicial. Ese segundo punto aparece como advertencia en la página del manual de find y ha costado a muchas personas su /var/log.

También puede considerar rsync -a --delete /srv/app/ /backup/app/. La barra final en el origen significa «el contenido de este directorio». Si la quita, obtiene /backup/app/app/. Si añade --delete, se elimina del destino todo lo que falte en el origen. Esto es correcto para un espejo y desastroso si la ruta de origen es incorrecta.

Verifique con la herramienta, no con el modelo:

rsync -a --delete --dry-run /srv/app/ /backup/app/ | head -20
find /var/log -name '*.gz' -mtime +7

Ejecute el find sin -delete y obtendrá una lista en lugar de una pérdida.

Modo de fallo: alucinación de indicadores. El modelo es fiable con herramientas que tienen treinta años de documentación y mucho menos fiable con las CLI (interfaces de línea de comandos) de los proveedores y los subcomandos recientes. En esos casos, produce un indicador que parece correcto pero no existe. --help lo confirma en un segundo. Las comillas son otro punto débil. Por eso, cuando un comando incluye una expresión $(...), lea cómo se expande la sustitución de comandos antes de ejecutar el comando en lugar de confiar en la explicación.

Tarea 5: convierte el historial del shell en un runbook

Acabas de dedicar dos horas a conseguir que algo funcionara. Ese conocimiento está en el historial desplazable de la terminal y desaparecerá el mes que viene.

history 200 > /tmp/session.txt

Lee ese archivo y elimina todas las líneas que contengan una contraseña, un token o un identificador de cliente antes de enviarlo a cualquier sitio. El historial del shell es uno de los lugares más fiables para encontrar un secreto en un sistema Linux, porque todo el mundo escribe alguno directamente al menos una vez. Configura HISTCONTROL=ignorespace en tu ~/.bashrc; así, un comando escrito con un espacio inicial nunca se guarda en el historial.

El prompt que produce un runbook utilizable solicita comprobaciones, no sólo pasos:

Esta es una sesión de shell que convirtió un sistema Debian 13 recién instalado en una instalación funcional de Postgres. Documenta el proceso como un runbook numerado. Usa un comando por paso. Después de cada paso, indica el comando que demuestra que funcionó y describe cómo sería una salida correcta. Marca cualquier paso que dependa de mi host específico.

Modo de fallo: una historia ordenada. En tu sesión hubo un paso que hiciste mal dos veces antes de corregirlo. Ese es el paso que el modelo elimina, porque la transcripción parece más limpia sin él. Compara el runbook con tu historial y vuelve a incluir la corrección. También inventa comandos de verificación plausibles, así que ejecuta todas las comprobaciones que escriba antes de guardar el archivo. Si el runbook cubre el primer arranque, compáralo con los primeros diez minutos en un VPS nuevo para no documentar una versión peor de un problema ya resuelto.

Trabajo 6: convertir un mensaje de error en una solución

Pegue la cadena exacta, el comando que la produjo y el único cambio que hizo antes de que apareciera. Pida las causas ordenadas por probabilidad y un comando distintivo para cada una. Esto obliga a que la respuesta sea comprobable.

nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use). Ordena las causas probables y dame un comando por causa que permita confirmarla o descartarla.

En este error, el mecanismo no es ambiguo: otro proceso ya ocupa el puerto 80 y sudo ss -tulpn | grep ':80 ' lo identifica. A menudo se trata de un segundo proceso maestro de nginx que quedó activo después de una recarga fallida, o de Apache, que se incorporó como dependencia y se inició desde su propio paquete.

Modo de fallo: una solución que funciona ocultando la causa. chmod 777, --privileged, desactivar SELinux y ejecutar el servicio como root hacen que el error desaparezca. Rechace cualquier solución que amplíe los permisos hasta que el modelo explique por qué falló el permiso limitado. Esa explicación es la respuesta real. Una solución alternativa sólo silencia el error.

Lo que hace mal de forma sistemática

• No puede ver su sistema. Cada respuesta depende de lo que haya pegado, y no le indicará que el fragmento era demasiado corto.
• Pierde precisión con las versiones. Los nombres de los paquetes y las opciones predeterminadas cambian entre distribuciones y versiones, y el modelo hace una media entre todas ellas.
• Se expresa con fluidez cuando se equivoca. Un mecanismo inventado se lee exactamente como uno correcto. Por eso, cada causa anterior incluye un comando que permite comprobarla.
• Pierde el hilo en sesiones largas. Los datos del principio de una conversación de dos horas dejan de influir en las respuestas del final.

Este último punto es más un problema operativo que un problema del modelo. gestionar el contexto en una sesión larga de Claude Code es la solución práctica: sesiones más cortas y una sola tarea en cada una.

Instalar el agente en el propio servidor

Todo lo anterior consiste en copiar y pegar, por lo que el modelo nunca toca su máquina. Cuando se ejecuta en el sistema, lee archivos y ejecuta comandos, y la naturaleza del riesgo cambia: un comando incorrecto puede dejar un servicio fuera de funcionamiento. Asígnele un usuario sin privilegios en lugar de root, manténgalo fuera del servidor de producción mientras conoce su comportamiento y cree primero una instantánea. Ejecutar Claude Code de forma segura en un VPS explica el aislamiento y el modelo de permisos. Ejecutar Claude Code dentro de tmux resuelve la otra mitad del problema, porque una sesión SSH (secure shell) interrumpida termina un agente en primer plano antes de que complete su trabajo. Cree la cuenta como crearía cualquier cuenta de servicio; usuarios con privilegios mínimos en un VPS explica cómo hacerlo.

FAQ

¿Claude puede leer directamente los registros de mi servidor?

No por sí solo. La interfaz de chat sólo ve el texto que pega en ella. Claude Code, ejecutado en el servidor como herramienta de línea de comandos, puede leer archivos y ejecutar comandos con los permisos del usuario que lo inició. Esto implica una decisión de confianza más importante. Para una consulta de soporte habitual, pegar un extracto de 100 líneas con los datos confidenciales ocultos es más rápido y seguro que dar acceso de shell a un agente.

¿Qué no debo pegar nunca de un servidor?

Claves privadas, archivos .env y otros almacenes de credenciales, /etc/shadow, y cualquier dato perteneciente a sus usuarios. Oculte los tokens de los extractos de registros antes de incluirlos en el prompt. Un caso menos evidente: la salida de docker compose config contiene sus valores .env interpolados. Use docker compose config -q, que valida el archivo y no imprime nada.

¿Es seguro permitir que Claude ejecute comandos en un VPS de producción?

Trátelo como a un administrador nuevo sin contexto: está bien para leer, pero las operaciones de escritura requieren revisión. En producción, pida la explicación y ejecute usted mismo el comando. Si quiere que un agente ejecute comandos, asígnele una cuenta sin privilegios dedicada y sin acceso sudo general. Empiece en un sistema de staging, donde un error le obligue a reconstruir el sistema en lugar de provocar una interrupción del servicio.

¿Por qué Claude sugiere un flag que no existe?

Porque predice texto plausible, y un flag plausible tiene el mismo aspecto que uno real. Ocurre sobre todo con las CLI de proveedores y los subcomandos nuevos, cuya documentación disponible para el modelo es escasa o ha cambiado desde entonces. --help y man son la referencia definitiva. Cualquier comando que elimine o sobrescriba datos debe probarse primero con una ejecución en seco.

¿Cómo compruebo una unidad de systemd antes de habilitarla?

Ejecute sudo systemd-analyze verify /etc/systemd/system/myapp.service. Analiza el archivo con el analizador propio de systemd, informa de las directivas desconocidas con sus números de línea y señala si falta un binario ExecStart o no es ejecutable. Después ejecute daemon-reload, start y lea systemctl status antes de enable, porque una unidad puede cargarse correctamente y aun así fallar en su primera ejecución.