Comandos avanzados de Linux para administrar servidores

Los comandos avanzados de Linux son los que usa quien responde por un servidor. Dicen por qué un servicio no arranca, qué llenó el disco y quién entró anoche. Esta guía reúne más de 150 comandos Linux para servidores, agrupados por tarea: servicios, discos, usuarios, comandos de red en Linux y cómo ver logs en Linux. Está pensada para la administración de servidores Linux, tanto si ya es su oficio como si empieza a hacerse cargo de uno.

No las copiamos de un manual. Montamos un servidor de prueba con Debian 13 y ejecutamos cada orden antes de escribirla. Por eso la guía incluye lo que el manual no avisa: tres trampas que hacen perder tiempo y dos averías de disco que df no explica.

Si todavía no se mueve con soltura por la terminal, empiece por nuestra guía de comandos básicos de Linux. Allí están ls, cd, grep y chmod, que aquí se dan por sabidos.

Qué son los comandos avanzados de Linux

No son órdenes más difíciles de escribir. Son las que cambian el estado de un servidor o explican una falla. En otras palabras, la diferencia está en la pregunta que responden:

Tarea	Nivel básico	Nivel avanzado
Servicios	Ver si un servicio está en marcha	Saber por qué falló y hacer que se levante solo
Registros	Leer las últimas líneas de un archivo	Filtrar por servicio, gravedad y hora
Disco	Ver cuánto espacio queda	Ampliar un volumen sin detener nada
Red	Hacer ping a un equipo	Ver qué proceso escucha en cada puerto
Usuarios	Cambiar una contraseña	Delegar una sola tarea de administrador
Automatización	Repetir una orden a mano	Programarla y saber si falló

A quién le sirven estos comandos de Linux

Sirve, sobre todo, a quien administra servidores: el área de TI de una empresa, el soporte de segundo nivel o un desarrollador que publica sus propias aplicaciones. Sin embargo, también le sirve a un usuario con un servidor en la nube, un NAS o una Raspberry Pi en casa. Por eso, cada apartado explica primero para qué sirven esos comandos avanzados de Linux y después cómo se escriben.

Dónde probamos los comandos Linux para servidores

El servidor de prueba fue un Debian 13.7 con systemd 257, Bash 5.2 y OpenSSH 10.0. Lo levantamos dentro de un contenedor de Docker, con systemd como primer proceso y un usuario normal con sudo, igual que en un servidor real. Tenía un servidor web nginx, dos discos virtuales de 1 GB para LVM y una segunda cuenta a la que entrar por SSH.

Un dato para dimensionar la tarea: ese sistema ofrecía 608 órdenes distintas a un usuario normal. Un administrador usa a diario unas cuarenta. Los comandos avanzados de Linux de esta guía son los que más resuelven.

En Ubuntu Server las órdenes son las mismas, porque comparte base con Debian. Por otro lado, en la familia Red Hat (AlmaLinux, Rocky Linux, RHEL) cambian los paquetes y el nombre de algún servicio. Lo detallamos más abajo, con las equivalencias que comprobamos en AlmaLinux 9.

Cómo leer los ejemplos

• Las órdenes con sudo delante necesitan permisos de administrador.
• Los nombres son de ejemplo: el servicio nginx, la usuaria ana, el segundo servidor srv-02 y los discos /dev/vdb y /dev/vdc. Cámbielos por los suyos.
• Los bloques se pueden copiar tal cual. Los ejecutamos así, línea por línea.

Además, practique primero en una máquina virtual. Puede montarla con Hyper-V o con VirtualBox en su propio equipo, y romperla sin consecuencias.

Servicios: comandos avanzados de Linux con systemctl

En un Linux actual, casi todo lo que corre en segundo plano es un servicio de systemd. Por tanto, systemctl es la primera orden que conviene dominar. Estas seis responden a la pregunta «¿qué está corriendo y qué falló?»:

systemctl status nginx
systemctl is-active nginx
systemctl is-enabled nginx
systemctl --failed
systemctl list-units --type=service --state=running
systemctl list-timers --all

La primera muestra el estado, la memoria, los procesos y las últimas líneas del registro. La segunda y la tercera responden con una sola palabra, así que sirven dentro de un guion. La cuarta, en cambio, lista solo lo que falló: es la que se mira primero al entrar a un servidor. En nuestro equipo había nueve servicios en marcha y trece temporizadores.

Arrancar, recargar y habilitar

Orden	Qué hace
sudo systemctl reload nginx	Vuelve a leer la configuración sin cortar las conexiones abiertas
sudo systemctl restart nginx	Detiene el servicio y lo arranca de nuevo
sudo systemctl disable --now nginx	Lo detiene y evita que arranque con el sistema
sudo systemctl mask nginx	Impide arrancarlo, incluso a mano
sudo systemctl unmask nginx	Deshace el bloqueo anterior
sudo systemctl enable --now nginx	Lo arranca ya y lo deja habilitado para el arranque
sudo systemctl daemon-reload	Hace que systemd lea los archivos de unidad que cambiaron

Dos detalles ahorran sustos. Primero, enable sin --now no arranca nada: solo lo deja listo para el próximo reinicio. Segundo, reload es preferible a restart cuando el servicio lo admite, porque no corta a quien está conectado.

Por qué falla un servicio

Como ejemplo usamos reporte, un servicio propio que lanza un guion y que creamos más abajo, en el apartado de tareas programadas. Lo dejamos fallando a propósito:

systemctl status reporte
sudo journalctl -u reporte -n 20
systemctl cat reporte
systemd-analyze verify /etc/systemd/system/reporte.service

En nuestra prueba, la primera orden respondió failed (Result: exit-code) y status=3. Es decir, el guion terminó con el código de error 3. La segunda mostró lo que el guion escribió antes de morir. La tercera enseña el archivo de unidad tal como systemd lo lee, y la cuarta revisa su sintaxis.

Además, systemctl status devuelve un código distinto de cero cuando el servicio no está activo. Lo mismo hace systemctl is-active. Por eso un guion puede decidir con ellas, sin leer el texto.

Reinicio automático sin tocar el archivo original

Nunca edite los archivos de /usr/lib/systemd/system: la siguiente actualización los pisa. En su lugar, sudo systemctl edit nginx abre un editor y guarda solo sus cambios en un archivo aparte. Para que el servicio se levante solo si se cae, basta con este contenido:

[Service]
Restart=on-failure
RestartSec=5

Después, compruebe que funciona:

systemctl show nginx -p Restart
sudo kill -9 $(pgrep -o nginx)
sleep 7
systemctl is-active nginx

En Debian, nginx viene con Restart=no: si el proceso muere, se queda muerto. Con el cambio, lo matamos a la fuerza y a los seis segundos estaba de nuevo active. El registro lo confirmó con la línea «Scheduled restart job, restart counter is at 1».

Registros: cómo ver logs en Linux con journalctl

El diario de systemd reúne los mensajes del núcleo y de todos los servicios. Se consulta con journalctl. Entre los comandos avanzados de Linux, es el que más tiempo ahorra, gracias a su filtro. En nuestro servidor, el diario del arranque tenía miles de líneas, y menos del 1 % eran errores.

Primera trampa: sin permisos, el diario parece vacío. Como usuario normal, journalctl -u nginx nos respondió «No entries». No era cierto: el usuario solo ve sus propios mensajes. Por tanto, use sudo, o añada su usuario al grupo systemd-journal.

sudo journalctl -u nginx --since today
sudo journalctl -p err -b
sudo journalctl -k -b
sudo journalctl --since "1 hour ago" --until "10 minutes ago"
sudo journalctl -u ssh -g "Invalid user|Accepted"
sudo journalctl --disk-usage

La primera línea muestra lo que un servicio dijo hoy. La segunda, solo los errores desde el último arranque. La tercera trae los mensajes del núcleo, donde aparecen las fallas de disco y de memoria. La cuarta acota por hora, y la quinta busca un texto. Por último, la sexta dice cuánto ocupa el diario.

Orden	Qué hace
sudo journalctl -u nginx -n 50	Muestra las últimas 50 líneas de un servicio
sudo journalctl -u nginx -o json -n 1	Entrega cada mensaje con todos sus campos, para procesarlo
sudo journalctl --list-boots	Lista los arranques que guarda el diario
sudo journalctl _COMM=sudo --since today	Muestra cada orden que alguien ejecutó hoy con sudo
sudo journalctl --vacuum-time=30d	Borra del diario lo que tenga más de 30 días
sudo journalctl --vacuum-size=200M	Reduce el diario hasta ocupar 200 MB

Para seguir un registro en vivo, añada -f: la orden se queda abierta y muestra cada línea nueva. Se sale con Ctrl + C.

En cuanto al espacio, el diario se limita solo. Según el manual de journald.conf, ocupa como máximo el 10 % del sistema de archivos, con un tope de 4 GB. Aun así, en un disco pequeño conviene vigilarlo.

Los registros que no pasan por el diario

Muchos programas escriben sus propios archivos en /var/log. Por ejemplo, nginx anota allí cada visita. Para que esos archivos no llenen el disco existe logrotate, que los rota, los comprime y borra los viejos:

ls /etc/logrotate.d/
cat /etc/logrotate.d/nginx
sudo logrotate -d /etc/logrotate.d/nginx
sudo dmesg -T --level=err,warn

La tercera orden es una simulación: dice qué haría sin tocar nada. En nuestro Debian, la regla de nginx rota a diario y guarda 14 archivos. La última línea, por su parte, lee el búfer del núcleo con la fecha legible.

Procesos y rendimiento: comandos de Linux para ver qué consume el servidor

Cuando alguien avisa de que «el servidor está lento», estos comandos avanzados de Linux dicen cuál de los cuatro recursos falta: procesador, memoria, disco o red.

ps -eo pid,user,%cpu,%mem,rss,etime,cmd --sort=-%mem | head -n 6
pgrep -a nginx
uptime
vmstat 1 5
free -h
iostat -xz 1 3
cat /proc/pressure/io

Cada una se lee de una forma concreta:

Orden	En qué fijarse
ps con --sort=-%mem	Los procesos que más memoria ocupan, con el tiempo que llevan en marcha
uptime	La carga media: si supera el número de núcleos, hay cola
vmstat 1 5	La columna r (procesos en espera), si y so (uso de intercambio) y wa (espera de disco)
free -h	La columna available, no free: Linux usa la memoria libre como caché
iostat -xz 1 3	%util y los tiempos await de cada disco
cat /proc/pressure/io	El porcentaje de tiempo que los procesos pasaron esperando al disco

El número de núcleos lo da nproc. Así, una carga de 4 es grave en un servidor de dos núcleos y trivial en uno de veinte. Por otro lado, iostat viene en el paquete sysstat, que no siempre está instalado.

El último archivo merece una nota. La información de presión del núcleo mide cuánto tiempo estuvieron detenidos los procesos por falta de un recurso. Existe también para cpu y para memory, y avisa antes que la carga media.

Señales y prioridades

Cerrar un proceso es enviarle una señal. Además, se puede pausar o bajarle la prioridad sin cerrarlo:

sleep 300 &
renice -n 5 -p $!
kill -STOP $!
kill -CONT $!
kill $!
timeout 2 sleep 10

La primera línea deja un proceso de prueba en segundo plano, y $! es su identificador. Después, renice le baja la prioridad, -STOP lo congela y -CONT lo reanuda. Por último, kill a secas le pide que termine, y timeout corta cualquier orden que pase del tiempo indicado.

En cambio, kill -9 no pide nada: el núcleo elimina el proceso sin dejarle guardar. Úselo solo cuando la señal normal no funcione.

Qué archivos y puertos tiene abiertos un proceso

sudo lsof -i :80
sudo ss -tlnp
strace -c ls /etc

La primera dice qué proceso ocupa el puerto 80, que es la duda habitual cuando un servicio no arranca por «dirección en uso». La segunda lista todos los puertos en escucha con su proceso. La tercera cuenta las llamadas al sistema de un programa: en nuestra prueba, un simple ls hizo 36 aperturas de archivo. Es la herramienta para un programa que falla sin dar ningún mensaje.

Discos y LVM: comandos avanzados de Linux para el almacenamiento

El disco es la causa más común de una caída evitable. Por eso, estas órdenes van antes que cualquier otra revisión:

lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINT
df -hT
df -i
findmnt /
sudo du -xh --max-depth=1 /var | sort -rh | head
sudo find / -xdev -type f -size +100M -exec ls -lh {} +

La primera dibuja los discos, sus particiones y dónde están montados. La segunda muestra el espacio de cada sistema de archivos y su tipo. La tercera, en cambio, cuenta inodos, que también se agotan, como verá más abajo. Las dos últimas responden «¿qué ocupa tanto?»: una ordena las carpetas por tamaño y la otra busca archivos de más de 100 MB.

La opción -x y su equivalente -xdev evitan que la búsqueda salte a otros discos montados. Sin ellas, la orden recorre también las unidades de red.

Ampliar un disco con LVM sin detener el servicio

LVM pone una capa entre los discos y los sistemas de archivos. Gracias a ella, un volumen puede crecer sumando otro disco, sin desmontar nada. Primero se crea:

sudo pvcreate /dev/vdb
sudo vgcreate vgdatos /dev/vdb
sudo lvcreate -L 500M -n lvdatos vgdatos
sudo mkfs.ext4 /dev/vgdatos/lvdatos
sudo mkdir -p /srv/datos
sudo mount /dev/vgdatos/lvdatos /srv/datos

Y cuando se queda corto, se amplía:

sudo vgextend vgdatos /dev/vdc
sudo lvextend -r -L +300M /dev/vgdatos/lvdatos
sudo lvextend -r -l +100%FREE /dev/vgdatos/lvdatos
sudo pvs
sudo vgs
sudo lvs
df -hT /srv/datos

La clave es la opción -r de lvextend: amplía el volumen y también el sistema de archivos, en un solo paso. En nuestra prueba, /srv/datos pasó de 459 MB a 740 MB, y después a 1,9 GB. Todo ocurrió con el volumen montado y en uso.

Sin embargo, hay dos advertencias. Primero, pvcreate y mkfs destruyen lo que haya en el disco: confirme el nombre con lsblk antes de escribirlos. Segundo, reducir es otra historia. Un ext4 solo se achica desmontado, y un XFS no se puede achicar.

Si su servidor es una máquina virtual, el disco nuevo se añade desde el hipervisor. Lo explicamos en la guía de Proxmox.

Que el montaje sobreviva al reinicio

Lo que se monta a mano se pierde al reiniciar. Para que sea permanente se añade una línea a /etc/fstab, y se comprueba antes de reiniciar:

echo "/dev/vgdatos/lvdatos /srv/datos ext4 defaults,nofail 0 2" | sudo tee -a /etc/fstab
sudo systemctl daemon-reload
sudo findmnt --verify
sudo mount -a

Una línea mal escrita en ese archivo puede dejar al servidor sin arrancar. Por eso existe findmnt --verify. En nuestra prueba añadimos una línea con un volumen que no existía, y la orden respondió «unreachable on boot required target» y terminó con error. Además, la opción nofail permite que el sistema arranque aunque ese disco falte.

Caso 1: el disco está lleno y los archivos no aparecen

Es una avería clásica. El monitoreo avisa de que el disco se llena, pero al sumar los archivos no salen las cuentas. Lo reprodujimos en el servidor de prueba:

df -h /srv/datos
sudo du -sh /srv/datos
sudo lsof +L1

La primera orden dijo que había 1,2 GB usados, el 67 % del volumen. La segunda, en cambio, solo encontró 13 KB. La tercera lo explicó: un proceso tail mantenía abierto un archivo app.log de 1,2 GB que alguien había borrado.

En Linux, borrar un archivo solo quita su nombre. El espacio no vuelve hasta que el último proceso lo cierra. Por tanto, la solución es reiniciar el servicio que lo tiene abierto. Al hacerlo, el volumen bajó del 67 % al 1 %.

La lección es sencilla: no borre con rm un registro que está en uso. Vacíelo con sudo truncate -s 0 seguido del nombre del archivo, o deje que logrotate haga su trabajo.

Caso 2: «No space left on device» con el disco vacío

La segunda avería desconcierta más. El sistema dice que no queda espacio, y df -h muestra el disco casi vacío:

df -h /mnt/pequeno
df -i /mnt/pequeno
sudo du --inodes -x /mnt/pequeno | sort -rn | head -n 5

En nuestra prueba, la primera orden mostró un 1 % de uso y 54 MB libres. Aun así, crear un archivo fallaba. La segunda dio la causa: 2.048 inodos de 2.048, el 100 %. La tercera señaló la carpeta culpable, con 2.036 archivos diminutos.

Cada archivo consume un inodo, por pequeño que sea. En ext4, esa cantidad se fija al crear el sistema de archivos y no se puede ampliar después. Así, millones de archivos de sesión o de caché pueden agotar los inodos mucho antes que el espacio. La salida es borrar los que sobran:

sudo find /mnt/pequeno/sesiones -type f -mtime +7 -delete

Esa orden borra los archivos con más de siete días. Ejecútela primero sin -delete, para ver qué encontraría.

Texto: comandos de Linux para filtrar registros con grep, awk y sed

Un registro de un millón de líneas no se lee: se resume. Estas cuatro órdenes sacan cuentas del registro de visitas de nginx:

sudo awk '{print $9}' /var/log/nginx/access.log | sort | uniq -c | sort -rn
sudo awk '$9 >= 400 {print $9, $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head
sudo awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -n 5
sudo awk '{bytes += $10} END {printf "%.1f KB en %d peticiones\n", bytes/1024, NR}' /var/log/nginx/access.log

La primera cuenta las respuestas por código. La segunda lista las direcciones que más errores dieron. La tercera ordena a los visitantes por número de peticiones, y la cuarta suma el tráfico servido.

En nuestro servidor hicimos 77 peticiones de prueba. El resultado fue 47 respuestas correctas, 27 «no encontrado» y 3 rechazadas. Además, la segunda orden mostró el patrón que verá en cualquier servidor público: 17 intentos sobre /wp-login.php y 9 sobre /.env. Son robots que buscan paneles y contraseñas.

La combinación sort | uniq -c | sort -rn es la más útil de los comandos avanzados de Linux de esta guía. Agrupa lo repetido, lo cuenta y lo ordena de mayor a menor.

Segunda trampa: grep -r no sigue los enlaces simbólicos

grep -rn "listen" /etc/nginx/sites-enabled/
grep -Rn "listen" /etc/nginx/sites-enabled/

La primera línea no encontró nada. La segunda, en cambio, encontró seis coincidencias. La diferencia es una letra. Según el manual de grep, -r salta los enlaces simbólicos que encuentra al recorrer una carpeta, y -R los sigue.

El problema es que muchas carpetas de configuración están hechas de enlaces. Por ejemplo, la de sitios activos de nginx. Así, una búsqueda con -r puede decir que una opción no está, cuando sí está.

Editar y comparar sin abrir un editor

grep -Ev '^\s*(#|$)' /etc/ssh/sshd_config
awk -F: '$3 >= 1000 && $3 < 65000 {print $1, $6, $7}' /etc/passwd
sudo sed -i.bak 's/worker_connections 768;/worker_connections 1024;/' /etc/nginx/nginx.conf
diff /etc/nginx/nginx.conf.bak /etc/nginx/nginx.conf
sudo nginx -t
sudo find /etc -type f -mmin -60
sudo journalctl -u ssh -o json -n 5 | jq -r '.MESSAGE'

La primera muestra un archivo de configuración sin comentarios ni líneas vacías. La segunda lista las cuentas de personas, con su carpeta y su intérprete. La tercera cambia un valor y, gracias a -i.bak, guarda una copia del original. Después, diff enseña exactamente qué cambió, y nginx -t valida la sintaxis antes de recargar.

Por último, find con -mmin -60 responde a una pregunta frecuente tras una falla: «¿qué se tocó en la última hora?». Y jq extrae un campo de una salida en JSON, como la del diario.

Comandos de red en Linux para diagnosticar

Los comandos de red en Linux cambiaron. Los clásicos, ifconfig, netstat y route, ya no vienen instalados en Debian 13. Lo comprobamos: ninguno de los tres estaba. Sus reemplazos son ip y ss:

Orden antigua	Orden actual	Qué muestra
ifconfig	ip -br a	Las interfaces y sus direcciones
route	ip route	La tabla de rutas
netstat -tulpn	sudo ss -tulpn	Los puertos en escucha y su proceso
arp	ip neigh	Los equipos vecinos en la red local

Con ellas, y con tres más, se recorre el camino completo de una conexión:

ip -br a
ip route get 1.1.1.1
sudo ss -tulpn
ss -s
dig +short www.kharonte.com
dig +short kharonte.com MX
nc -zv -w 3 www.kharonte.com 443

El orden importa. Primero, si la interfaz tiene dirección. Después, por dónde saldría un paquete hacia un destino. Luego, qué escucha el servidor y cuántas conexiones tiene. A continuación, si el nombre resuelve. Y por último, si el puerto de destino responde. La orden dig viene en el paquete bind9-dnsutils.

Si quiere repasar los conceptos, los explicamos en la guía de la red de área local y en la del servidor DNS.

Medir dónde se va el tiempo de una página

curl -sS -o /dev/null -w 'dns %{time_namelookup}s · conexion %{time_connect}s · tls %{time_appconnect}s · primer byte %{time_starttransfer}s · total %{time_total}s · HTTP %{http_code}\n' https://www.kharonte.com/
echo | openssl s_client -connect www.kharonte.com:443 -servername www.kharonte.com 2>/dev/null | openssl x509 -noout -dates

La primera orden desglosa una petición web en sus etapas. Cada cifra es el tiempo acumulado hasta ese punto. En nuestra prueba, el nombre se resolvió en 4 milésimas, y la conexión cifrada quedó lista a las 119. Por tanto, la red apenas pesaba: el resto era el servidor preparando la página. Así se sabe a quién reclamar.

La segunda, por su parte, lee las fechas del certificado de un sitio. Es la forma rápida de saber cuándo vence, sin abrir un navegador.

Ver el tráfico con tcpdump

sudo timeout 10 tcpdump -i any -nn -c 20 port 80

Cuando dos equipos no se entienden, tcpdump muestra los paquetes que de verdad llegan. Aquí captura hasta 20 del puerto 80, en cualquier interfaz, y timeout lo detiene a los diez segundos. La opción -nn evita que traduzca direcciones y puertos a nombres.

En cuanto al firewall, cada familia usa el suyo: ufw en Ubuntu, firewalld en Red Hat y nftables por debajo de ambos. No los probamos, porque nuestro servidor era un contenedor sin firewall propio. Para el perímetro de una oficina, vea las guías de pfSense y de MikroTik.

Usuarios, permisos y sudo: comandos de Linux para delegar

Dar de alta a una persona, limitar lo que puede hacer y retirarle el acceso son tareas de todos los meses. Estos comandos avanzados de Linux cubren el ciclo completo de una cuenta:

sudo useradd -m -s /bin/bash -c "Ana Gomez" ana
sudo usermod -aG adm ana
id ana
sudo chage -M 90 -W 7 ana
sudo chage -l ana
sudo usermod -L ana
sudo passwd -S ana
sudo usermod -U ana

La primera crea la cuenta con su carpeta personal. La segunda la añade a un grupo, y id lo confirma. Después, chage obliga a cambiar la contraseña cada 90 días, con siete de aviso. Por último, usermod -L bloquea la cuenta sin borrarla, que es lo prudente cuando alguien deja la empresa, y -U la desbloquea. La contraseña se asigna con sudo passwd ana, que la pide dos veces.

Tercera trampa: usermod -G sin la -a quita los demás grupos. Lo comprobamos. La usuaria estaba en adm y en soporte; tras un usermod -G soporte ana, solo quedó en soporte. La opción -a significa «añadir». Sin ella, la lista se reemplaza.

Delegar una tarea de administrador sin entregar todo

No hace falta dar sudo completo a quien solo debe reiniciar un servicio. Una regla en /etc/sudoers.d/soporte lo limita a esa orden:

%soporte ALL=(root) /usr/bin/systemctl restart nginx, /usr/bin/systemctl status nginx

El archivo se crea con sudo visudo -f /etc/sudoers.d/soporte, que revisa la sintaxis al guardar. Después se crea el grupo, se añade a la persona y se comprueba el resultado:

sudo groupadd soporte
sudo gpasswd -a ana soporte
sudo visudo -c
sudo -l -U ana

La última orden lista lo que esa usuaria puede ejecutar como administrador. En nuestra prueba mostró exactamente las dos órdenes de la regla. Además, nunca edite esos archivos con un editor normal. Cuando probamos visudo -c con un archivo mal escrito, respondió «syntax error». Un error así, guardado sin revisar, deja a todos sin sudo.

Carpetas compartidas: setgid y listas de acceso

sudo mkdir -p /srv/datos/contabilidad
sudo chown root:soporte /srv/datos/contabilidad
sudo chmod 2770 /srv/datos/contabilidad
sudo setfacl -m u:operador:rx /srv/datos/contabilidad
getfacl -p /srv/datos/contabilidad
namei -l /srv/datos/contabilidad
sudo find / -xdev -type f -perm -4000

El 2 de 2770 activa el bit setgid. Con él, todo archivo nuevo de la carpeta hereda el grupo soporte, sin importar quién lo cree. Por otro lado, setfacl da acceso de lectura a un usuario concreto, operador en nuestra prueba, sin cambiar el grupo. Cuando una carpeta tiene una lista así, ls -l le añade un signo +.

Por su parte, namei -l muestra los permisos de cada tramo de una ruta. Es la respuesta rápida a «tengo permiso sobre el archivo y aun así no puedo abrirlo»: casi siempre falta el permiso en una carpeta superior.

La última orden lista los programas con el bit setuid, que se ejecutan con los permisos de su dueño. En nuestro Debian recién instalado había doce. Guarde esa lista: un programa nuevo en ella merece una explicación.

Quién entró y qué hizo

sudo journalctl -u ssh -g "Accepted|Invalid user" --since today
sudo journalctl _COMM=sudo --since today
who

La primera muestra los accesos por SSH aceptados y los intentos con usuarios que no existen. La segunda, cada orden ejecutada con sudo. La tercera, quién tiene una sesión abierta ahora.

Si echa de menos last, hay una razón. Según las notas de la versión, Debian 13 retiró last, lastb y lastlog. En nuestro servidor no estaban, y last volvió al instalar el paquete wtmpdb.

SSH: comandos de Linux para administrar varios servidores

La administración de servidores Linux se hace por SSH. Con llaves en lugar de contraseñas es más cómoda y más difícil de forzar:

ssh-keygen -t ed25519 -C "operador@srv-01"
ssh-copy-id ana@srv-02
ssh ana@srv-02 hostname

La primera crea el par de llaves y pregunta dónde guardarlo y con qué frase protegerlo. La segunda instala la llave pública en el otro servidor, y pide la contraseña por última vez. A partir de ahí, la tercera entra sin preguntar. En nuestra prueba, srv-02 era el mismo equipo con otro nombre y otra cuenta.

Un archivo de configuración para no repetir opciones

El archivo ~/.ssh/config guarda un alias por servidor:

Host srv-02
    HostName 10.0.0.12
    User ana
    IdentityFile ~/.ssh/id_ed25519
    ServerAliveInterval 60

Host interno
    HostName 10.0.5.20
    User ana
    ProxyJump srv-02

Con él, las órdenes se acortan:

ssh interno hostname
ssh -f -N -L 8080:localhost:80 srv-02
curl -sI http://localhost:8080/
rsync -avn --delete ~/informes/ srv-02:informes/
rsync -av --delete ~/informes/ srv-02:informes/

La primera llega a un servidor interno saltando por otro, gracias a ProxyJump. La segunda abre un túnel: el puerto 8080 de su equipo pasa a ser el 80 del servidor remoto. Así se consulta un panel interno sin publicarlo, como comprueba la tercera.

Las dos últimas copian una carpeta con rsync. La opción -n hace un ensayo y lista lo que cambiaría. Úsela siempre antes, porque --delete borra en el destino lo que ya no está en el origen. Con el origen y el destino cruzados, esa opción vacía la carpeta buena. Además, la barra final del origen importa: con ella se copia el contenido, y sin ella, la carpeta entera.

Endurecer el acceso

Las opciones de seguridad se añaden en un archivo propio, por ejemplo /etc/ssh/sshd_config.d/10-endurecer.conf:

PasswordAuthentication no
PermitRootLogin no
MaxAuthTries 3

Y se aplican después de comprobar la sintaxis:

sudo sshd -t
sudo systemctl reload ssh
sudo sshd -T | grep -E '^(permitrootlogin|passwordauthentication|maxauthtries) '

La orden sshd -T muestra la configuración efectiva, que es la que cuenta. En nuestro Debian 13, antes del cambio aceptaba contraseñas, permitía a root entrar con llave y daba seis intentos. Después, las tres opciones quedaron como en el archivo. En la familia Red Hat, el servicio se llama sshd.

Dos precauciones evitan quedarse fuera. Primero, compruebe que su llave funciona antes de desactivar las contraseñas. Segundo, deje una sesión abierta mientras prueba la nueva en otra ventana.

Por último, para un trabajo largo use tmux. Con tmux new -s trabajo abre una sesión que sigue viva aunque se corte la conexión. Se suelta con Ctrl + B y luego D, y se recupera con tmux attach -t trabajo.

Paquetes y actualizaciones: comandos de Linux en Debian y Ubuntu

Un servidor sin actualizar es el riesgo más barato de corregir. Estas órdenes dicen qué hay pendiente y qué se instaló:

sudo apt update
apt list --upgradable
apt-cache policy nginx
sudo apt-mark hold nginx
apt-mark showhold
sudo apt-mark unhold nginx
grep -A3 "Start-Date" /var/log/apt/history.log | tail -n 8
apt-config dump | grep -i periodic
sudo unattended-upgrade --dry-run -d

La segunda lista los paquetes con versión nueva. La tercera muestra de qué repositorio viene cada versión. Después, apt-mark hold congela un paquete que no debe cambiar todavía, y unhold lo libera. La séptima lee el historial: qué se instaló, cuándo y con qué orden.

Las dos últimas tienen que ver con las actualizaciones automáticas. Aquí hay un detalle que hemos visto en un servidor real, que pasó semanas sin actualizarse. El temporizador apt-daily existe y corre aunque nada esté configurado. Lo que manda es la salida de apt-config: si no aparecen las dos líneas Periodic con un «1», el servidor no se actualiza solo. La última orden lo ensaya sin instalar nada.

Además, apt list --upgradable responde según la última descarga de listas. Si esa descarga es de hace un mes, dirá que no hay nada pendiente. Por eso se ejecuta antes apt update.

Diferencias con AlmaLinux, Rocky Linux y RHEL

Comprobamos estas equivalencias en un AlmaLinux 9.8:

Tarea	Debian y Ubuntu	Familia Red Hat
Ver actualizaciones pendientes	apt list –upgradable	dnf check-update
Saber qué paquete trajo un archivo	dpkg -S	rpm -qf
Listar los archivos de un paquete	dpkg -L	rpm -ql
Historial de instalaciones	/var/log/apt/history.log	dnf history
Actualizaciones automáticas	unattended-upgrades	dnf-automatic
Congelar una versión	apt-mark hold	dnf versionlock
Nombre del servicio de SSH	ssh	sshd

Un aviso para los guiones: dnf check-update termina con el código 100 cuando hay actualizaciones. No es un error. Por otro lado, dnf versionlock necesita un complemento que se instala aparte.

Tareas programadas en Linux: comandos de cron y de systemd

La forma clásica de programar una tarea es cron. Cada usuario edita su lista con crontab -e y la consulta con crontab -l. Una línea tiene cinco campos de tiempo y una orden:

30 2 * * 1-5 flock -n /tmp/respaldo.lock /usr/local/bin/respaldo.sh >> /var/log/respaldo.log 2>&1

Esa línea se ejecuta a las 2:30, de lunes a viernes. Los campos son minuto, hora, día del mes, mes y día de la semana. El final, >> … 2>&1, guarda en un archivo tanto la salida como los errores. Sin él, nadie se entera de que la tarea falló.

Además, flock -n evita que dos copias corran a la vez. Lo probamos: con una en marcha, la segunda terminó de inmediato sin hacer nada. Y un aviso: crontab -r borra toda la lista sin preguntar. La r está junto a la e en el teclado.

El mismo trabajo con un temporizador

La alternativa moderna son dos archivos en /etc/systemd/system. El primero, reporte.service, dice qué ejecutar:

[Unit]
Description=Reporte diario de ocupacion

[Service]
Type=oneshot
ExecStart=/usr/local/bin/reporte.sh

El segundo, reporte.timer, dice cuándo:

[Unit]
Description=Lanza el reporte diario

[Timer]
OnCalendar=*-*-* 06:30:00
Persistent=true

[Install]
WantedBy=timers.target

Y se activa así:

sudo systemctl daemon-reload
sudo systemctl enable --now reporte.timer
systemctl list-timers reporte.timer
systemd-analyze calendar "Mon..Fri 02:00"
sudo journalctl -u reporte -n 10

Frente a cron, el temporizador tiene tres ventajas. Primero, la salida va al diario, sin redirecciones. Segundo, list-timers muestra cuándo será la próxima ejecución. Y tercero, Persistent=true recupera la ejecución perdida si el servidor estaba apagado a esa hora. Por su parte, systemd-analyze calendar traduce una expresión de fecha y dice cuándo se cumple.

De hecho, el propio sistema ya trabaja así. De los trece temporizadores de nuestro Debian, varios hacen tareas que antes eran de cron: rotar registros, buscar actualizaciones y limpiar archivos temporales.

Bash para administradores de Linux: de comandos sueltos a un guion

Un guion es una lista de órdenes en un archivo. Este revisa tres servicios, avisa de los discos por encima del 80 % y lista lo que falló:

#!/usr/bin/env bash
set -euo pipefail

LIMITE=80
for servicio in nginx ssh cron; do
    printf '%-8s %s\n' "$servicio" "$(systemctl is-active "$servicio" || true)"
done

df -h --output=pcent,target -x tmpfs -x devtmpfs | awk -v limite="$LIMITE" 'NR>1 && $1+0 >= limite {print "disco al " $1 " en " $2}'
systemctl --failed --no-legend --plain | awk '{print "servicio caido: " $1}'

Guárdelo como revisar.sh, instálelo y pruébelo:

sudo install -m 755 revisar.sh /usr/local/bin/revisar.sh
bash -n /usr/local/bin/revisar.sh
revisar.sh

La segunda línea del guion es la más importante. Con set -euo pipefail, el guion se detiene ante el primer error, ante una variable sin definir y ante una falla en medio de una tubería. Lo comprobamos: sin esa línea, false | true se dio por bueno y el guion siguió. Con ella, se detuvo. Por su parte, bash -n revisa la sintaxis sin ejecutar nada.

Sin embargo, un guion así solo mira cuando alguien lo lanza. Para vigilar de forma continua hace falta un sistema que recoja los datos y avise. Lo explicamos en las guías de monitoreo de servidores y de Zabbix.

Diagnóstico en un minuto con comandos avanzados de Linux

Ante un servidor lento, el orden importa más que la herramienta. Esta lista adapta el método que Brendan Gregg publicó en Linux Performance Analysis in 60,000 Milliseconds, con dos órdenes de systemd añadidas:

uptime
sudo dmesg -T | tail
vmstat 1 5
free -h
df -hT
df -i
sudo ss -tulpn
systemctl --failed
sudo journalctl -p err -b -n 20
top -b -n 1 | head -n 15

Orden	Pregunta que responde
uptime	¿Hay más carga que núcleos? ¿Sube o baja?
sudo dmesg -T	¿El núcleo mató un proceso por falta de memoria o hay errores de disco?
vmstat 1 5	¿Falta procesador, memoria o disco?
free -h	¿Queda memoria disponible?
df -hT	¿Algún sistema de archivos está lleno?
df -i	¿Se agotaron los inodos?
sudo ss -tulpn	¿Escucha cada servicio donde debe?
systemctl --failed	¿Qué servicio se cayó?
sudo journalctl -p err -b -n 20	¿Qué errores hubo desde el arranque?

En total, se tarda un minuto. Y en la mayoría de los casos, una de esas respuestas ya señala la causa.

Comandos avanzados de Linux que exigen cuidado

Linux no pide confirmación. Por eso, estas órdenes se revisan dos veces antes de pulsar Intro:

Riesgo	Qué puede pasar	Cómo evitarlo
pvcreate o mkfs sobre el disco equivocado	Se pierde todo su contenido	Confirmar el nombre con lsblk
rsync con la opción de borrado	Con el origen y el destino cruzados, vacía la carpeta buena	Ensayar antes con la opción -n
crontab con la opción -r	Borra todas las tareas del usuario	Guardar antes una copia de la lista
usermod -G sin la -a	El usuario pierde sus otros grupos	Escribir siempre -aG
Una línea errónea en fstab	El servidor no arranca	Ejecutar findmnt con la opción de verificar
Editar sudoers con un editor normal	Nadie puede usar sudo	Usar siempre visudo
sed con edición directa	Cambia el archivo sin copia	Añadir un sufijo de copia, como .bak
Desactivar las contraseñas de SSH	Se queda fuera del servidor	Probar antes la llave y dejar una sesión abierta
kill con la señal 9	El proceso no guarda nada	Probar antes sin el 9

Lo que los comandos de Linux no resuelven

Saber los comandos avanzados de Linux es necesario, pero no basta. En una empresa, la administración de servidores Linux tiene cuatro huecos que ninguna terminal cubre:

• No avisan. Un comando responde cuando alguien pregunta. El disco se llena de madrugada.
• No guardan historia. Lo que vmstat mostró ayer a las tres ya no existe.
• Dependen de una persona. Si solo una sabe cómo está montado el servidor, ese es el riesgo.
• No dejan constancia. Un cambio hecho por SSH no queda escrito en ninguna parte, salvo que alguien lo anote.

Por tanto, los comandos avanzados de Linux son la herramienta del diagnóstico. La continuidad, en cambio, depende del monitoreo, de las copias probadas y de un registro de cada cambio.

Preguntas frecuentes sobre los comandos avanzados de Linux

¿Qué comandos de Linux debe saber un administrador?

Como mínimo, los de servicios (systemctl), registros (journalctl), disco (df, du, lsblk), red (ip, ss, dig), usuarios (useradd, usermod, visudo) y acceso remoto (ssh, rsync).

¿Sirven estos comandos de Linux en Ubuntu Server?

Sí. Ubuntu comparte base con Debian, así que los comandos avanzados de Linux de esta guía son los mismos. En la familia Red Hat cambian los paquetes, como muestra la tabla de equivalencias.

¿Cómo ver logs en Linux cuando hay errores?

Con sudo journalctl -p err -b, que muestra solo los errores desde el último arranque. Para un servicio concreto, añada -u y su nombre.

¿Por qué el disco aparece lleno si no encuentro los archivos?

Porque un proceso mantiene abierto un archivo borrado, o porque se agotaron los inodos. Lo primero se ve con sudo lsof +L1, y lo segundo, con df -i.

¿Qué diferencia hay entre cron y un temporizador de systemd?

Los dos programan tareas. El temporizador, además, guarda la salida en el diario y recupera las ejecuciones perdidas mientras el servidor estuvo apagado.

¿Es seguro probar comandos avanzados de Linux en producción?

Los de consulta, sí. Los que cambian discos, usuarios, sudo o SSH se prueban antes en una máquina virtual.

¿Cómo sé qué proceso usa un puerto?

Con sudo ss -tulpn, que lista cada puerto en escucha con su proceso, o con sudo lsof -i :80 para un puerto concreto.

Cómo lo aborda KHARONTE

Los comandos avanzados de Linux resuelven el momento, pero un servidor no se administra solo. Alguien tiene que actualizarlo, revisar sus registros, vigilar el disco y dejar escrito lo que cambió. En KHARONTE, ese trabajo pertenece a la línea de infraestructura y datacenter: dimensionamos, implementamos, administramos y migramos servidores, máquinas virtuales y almacenamiento. No comercializamos los equipos. El alcance está en nuestra página de infraestructura de TI.

Además, cada solicitud entra por nuestra mesa de ayuda TI, donde queda registrada y con responsable. Si lo que necesita es personal que opere sus servidores, vea el outsourcing de infraestructura de TI. Y si busca servicios administrados de TI que reúnan servidores, monitoreo y respaldo, conozca el resto de nuestros servicios de TI para empresas.