SSH para desarrolladores de WordPress: 10 comandos que salvarán su vida

Como desarrollador de WordPress, probablemente pasas mucho tiempo en un cliente FTP (FileZilla) o panel de hosting. Eso es un error. Lo que toma 15 minutos en FTP (ej. eliminar una carpeta cache con 100,000 archivos) toma 2 segundos en la terminal SSH.

En esta guía, te mostraré un conjunto de comandos que los desarrolladores sénior no pueden imaginar trabajar sin ellos.

#Por qué todo desarrollador de WordPress necesita SSH

Antes de sumergirnos en los comandos, entendamos por qué SSH es transformador para el desarrollo de WordPress:

• Velocidad: Las operaciones se ejecutan a la velocidad del disco del servidor, no de tu conexión a internet
• Automatización: Puedes crear scripts que automatizan tareas repetitivas
• Depuración en vivo: Ve errores en tiempo real mientras se producen
• Gestión remota: Administra servidores desde cualquier lugar del mundo
• Seguridad: Conexión cifrada de extremo a extremo

#Configuración inicial de SSH

Si nunca has usado SSH, aquí está como comenzar:

## Generar par de claves SSH (solo la primera vez)
ssh-keygen -t ed25519 -C "[email protected]"

## Copiar clave pública al servidor
ssh-copy-id usuario@ip-del-servidor

## Conectarse al servidor
ssh usuario@ip-del-servidor

La autenticación por claves es más segura que contraseñas y elimina la necesidad de escribir la contraseña cada vez.

#Cómo guardar los datos de acceso al servidor en ~/.ssh/config

Escribir cada vez ssh -p 2222 -i ~/.ssh/cliente_ed25519 [email protected] acaba con puertos y claves cruzados entre clientes. El cliente OpenSSH lee un archivo por usuario, ~/.ssh/config, donde cada servidor recibe un nombre corto (ssh_config(5)):

Host cliente-prod
    HostName s123.hosting.example
    User cliente
    Port 2222
    IdentityFile ~/.ssh/cliente_ed25519
    IdentitiesOnly yes

A partir de ahí ssh cliente-prod, scp, sftp y rsync toman esos valores por sí solos. Host abarca todas las líneas que tiene debajo hasta el siguiente bloque Host o Match, HostName es la dirección real del servidor y Port sustituye al 22 por defecto. Casi todas las sorpresas se explican con una regla del manual: para cada opción vale el primer valor encontrado, y ssh lee primero las opciones de la línea de comandos, después el archivo del usuario y al final el /etc/ssh/ssh_config del sistema. Pon por tanto los servidores concretos arriba del archivo y el bloque genérico Host * al final. En macOS, la guía de GitHub sobre claves SSH añade al mismo bloque AddKeysToAgent yes y UseKeychain yes, para escribir la frase de contraseña de la clave una sola vez y dejarla guardada en el llavero del sistema (GitHub Docs).

#Cómo solucionar el error too many authentication failures en SSH

El mensaje Too many authentication failures suele aparecerle a quien tiene claves para muchos servidores. El cliente ofrece al servidor, una tras otra, todas las claves que guarda ssh-agent, y el servidor cuenta cada intento rechazado. El límite lo fija la opción MaxAuthTries del servidor y por defecto es 6 (sshd_config(5)). Si la clave correcta está en el agente más allá de la sexta posición, el servidor cierra la conexión antes de verla. La solución está en el bloque de la sección anterior: IdentitiesOnly yes obliga a ssh a usar solo la clave configurada, aunque el agente ofrezca más (ssh_config(5)). Para una prueba puntual basta ssh -o IdentitiesOnly=yes -i ~/.ssh/cliente_ed25519 [email protected], y ssh -v muestra en las líneas Offering public key qué claves llegaron de verdad al servidor.

De la misma familia es la sesión que se congela en una conexión inestable. ServerAliveInterval 15 en el bloque del servidor hace que el cliente pida una respuesta al servidor cada 15 segundos por el canal cifrado. Con el ServerAliveCountMax por defecto de 3, el manual indica que ssh se desconecta tras unos 45 segundos de silencio, en lugar de dejarte con la terminal colgada.

#1. Cómo ver qué ocupa espacio en el servidor

Cuando el hosting grita “Cuota Excedida”, FileZilla no ayudara. Usa esto:

#du (disk usage)

## Mostrar carpetas en el directorio actual, ordenadas por tamaño
du -h --max-depth=1 | sort -hr

Ejemplo de salida:

2.1G    ./wp-content
450M    ./wp-content/uploads
380M    ./wp-content/cache
120M    ./wp-content/plugins
45M     ./wp-admin
12M     ./wp-includes

Inmediatamente puedes ver que la carpeta de cache consume 380MB y puede ser limpiada de forma segura.

#ncdu (ncurses disk usage)

Si puedes, ejecuta ncdu. Es un gestor interactivo que navega con las flechas. Un absoluto “cambio de juego” para la limpieza de servidores.

## Instalar ncdu (si no esta disponible)
apt-get install ncdu  # Debian/Ubuntu
yum install ncdu      # CentOS/RHEL

## Ejecutar en el directorio de WordPress
ncdu /var/www/html

Recurre a du cuando necesites una cifra que pegar en un ticket, y a ncdu cuando todavía no sepas qué estás buscando. Los dos recorren el árbol completo y eso no sale gratis: en una carpeta uploads grande mantienen el disco ocupado durante un minuto, y en alojamiento compartido eso se nota como páginas más lentas mientras corren. Si el sitio tiene visitas, apúntalos a un subdirectorio en lugar de a la raíz de la cuenta. Ninguno te dirá qué se puede borrar, y en una instalación de WordPress el candidato que más sorprende no suelen ser las imágenes sino las revisiones y los registros que algunos plugins de seguridad guardan en disco durante meses.

#2. Cómo ver el debug.log de WordPress en tiempo real

En lugar de descargar debug.log, abrirlo con Bloc de Notas y buscar errores… velos en vivo!

#tail -f

## Seguir las últimas líneas del archivo en tiempo real
tail -f wp-content/debug.log

Ahora refresca la página en tu navegador, y los errores aparecerán en pantalla. Sal con Ctrl+C.

#Filtrar logs en tiempo real

## Solo ver errores fatales
tail -f wp-content/debug.log | grep -i "fatal"

## Ver errores de un plugin específico
tail -f wp-content/debug.log | grep "woocommerce"

## Mostrar las últimas 100 líneas y luego seguir
tail -100f wp-content/debug.log

#Logs del servidor web

Además del debug.log de WordPress, los logs del servidor web son invaluables:

## Apache - ver errores
tail -f /var/log/apache2/error.log

## Nginx - ver errores
tail -f /var/log/nginx/error.log

## Cómo ver solicitudes 404 en tiempo real por SSH
tail -f /var/log/apache2/access.log | grep " 404 "

Seguir el log en vivo funciona mientras puedas provocar el error a voluntad. Cuando no puedes, la línea que te interesa ya pasó, así que empieza por tail -n 200 wp-content/debug.log y lee hacia atrás. Dos detalles se le escapan a casi todo el mundo. El archivo solo existe si WP_DEBUG_LOG está activo en wp-config.php, de modo que una terminal vacía suele significar que el registro está apagado, no que el sitio esté sano. Y nada rota ese archivo por su cuenta, así que un sitio que lanza un aviso en cada petición termina siendo él mismo quien llena la cuota que diagnosticaste en la sección anterior.

#3. Cómo buscar código en archivos de WordPress con grep

Buscando donde se uso add_image_size? No descargues todo el proyecto.

#grep

## Buscar la frase "add_image_size" en todos los archivos PHP recursivamente
grep -r "add_image_size" .

Si solo quieres una lista de archivos (sin contenido):

grep -rl "add_image_size" .

#Búsquedas avanzadas con grep

## Buscar con contexto (3 líneas antes y después)
grep -r -C 3 "wp_enqueue_script" wp-content/themes/

## Buscar solo en archivos PHP
grep -r --include="*.php" "add_action" wp-content/plugins/

## Buscar excluyendo directorios
grep -r --exclude-dir={node_modules,vendor,.git} "API_KEY" .

## Contar ocurrencias
grep -rc "do_action" wp-content/plugins/ | sort -t: -k2 -rn | head -10

La forma completa sirve para leer el código alrededor del resultado, y la versión con -l cuando solo quieres saber qué plugin es responsable de un comportamiento. Dentro de un tema el coste es despreciable, dentro de wp-content/plugins no lo es, porque la recursión entra en cada carpeta vendor que encuentre. Confirma un resultado abriendo el archivo en esa línea en lugar de fiarte del recuento: el mismo nombre de función aparece en el código del plugin, en el bloque de documentación que lo precede y en el archivo de traducción, y solo uno de esos tres sitios es la definición.

#4. Cómo solucionar el error 403 Forbidden con permisos de archivos

A menudo después de una migración, los archivos tienen permisos incorrectos. Recuerda la regla:

• Directorios: 755
• Archivos: 644

#find + chmod

No lo hagas manualmente. Automatízalo:

## Establecer 755 para todos los directorios
find . -type d -exec chmod 755 {} \;

## Establecer 644 para todos los archivos
find . -type f -exec chmod 644 {} \;

#Permisos de wp-config.php y .htaccess

## wp-config.php debe ser más restrictivo
chmod 400 wp-config.php

## .htaccess
chmod 444 .htaccess

## Verificar propietario de los archivos
chown -R www-data:www-data /var/www/html/

Ejecuta esto cuando tengas un síntoma, un 403 o una subida que falla, y no como mantenimiento rutinario. Un chmod aplicado a todo aplana cualquier excepción deliberada de la instalación, y la que importa es wp-config.php, que guarda las credenciales de la base de datos. El bucle solo toca los archivos que pertenecen a tu usuario, de manera que en un alojamiento donde el servidor web corre con otra cuenta puede no arreglar nada y no devolver ningún error. Comprueba el resultado con ls -l wp-config.php y cargando la página que fallaba, nunca repitiendo el mismo comando.

#5. Cómo hacer una copia de seguridad de WordPress con tar por SSH

Quieres un respaldo rápido antes de una actualización? No copies vía FTP (tarda una eternidad). Comprímelo en el servidor.

#tar

## Crear archivo backup.tar.gz del directorio actual
tar -czf backup.tar.gz .

Descomprimir:

tar -xzf backup.tar.gz

#Respaldo con fecha y exclusión de carpetas

## Crear respaldo con marca de tiempo
tar -czf backup-$(date +%Y%m%d-%H%M).tar.gz .

## Excluir carpetas innecesarias del respaldo
tar -czf backup.tar.gz --exclude='./wp-content/cache' --exclude='./wp-content/uploads/cache' .

Comprimir en el servidor es el movimiento correcto antes de actualizar un plugin, porque el archivo nunca atraviesa tu conexión. No es una estrategia de respaldo: el paquete queda en el mismo disco que el sitio, así que sobrevive a una actualización fallida pero no a una avería del volumen. Y antes de confiar en él, mira dentro con tar -tzf backup.tar.gz | head, porque un archivo que se cortó a mitad de escritura por falta de espacio aparece en el listado como un archivo perfectamente normal.

#6. Cómo exportar e importar la base de datos con WP-CLI

Si tienes WP-CLI (y deberías), no necesitas phpMyAdmin.

## Cómo exportar la base de datos WordPress por SSH
wp db export backup.sql

## Importar base de datos
wp db import backup.sql

## Buscar y reemplazar (migración)
wp search-replace 'sitio-viejo.com' 'sitio-nuevo.com' --all-tables

## Listar usuarios
wp user list

## Cambiar contraseña
wp user update 1 --user_pass="NuevaContrasena2026"

## Desactivar todos los plugins (emergencia)
wp plugin deactivate --all

## Verificar integridad del core
wp core verify-checksums

#Comandos WP-CLI avanzados

## Optimizar base de datos
wp db optimize

## Ver tamaño de tablas
wp db size --tables

## Buscar en la base de datos
wp db search "texto_sospechoso"

## Regenerar miniaturas de imágenes
wp media regenerate --yes

## Limpiar transients expirados
wp transient delete --expired

WP-CLI corre como tu usuario de shell y no a través del servidor web, por lo que los límites de subida y max_execution_time dejan de aplicarse. Lo que no puedes ignorar es que el sitio está en producción: wp db import elimina y vuelve a crear las tablas mientras alguien está comprando, así que la ventana de mantenimiento forma parte del comando y no es un añadido. Para cambiar el dominio antiguo tras una migración, usa wp search-replace con --dry-run primero, como se explica en la sección sobre search-replace más abajo.

#7. Cómo borrar la carpeta de caché rápido por SSH

Eliminar una carpeta de plugin cache con un millón de archivos pequeños vía FTP puede tomar una hora.

#rm

## Eliminar carpeta y todo su contenido (sin deshacer!)
rm -rf wp-content/cache/

Tiempo empleado: 0.5 segundos.

#Cómo borrar archivos de caché con find de forma segura

## Ver qué se eliminaría primero (dry run)
find wp-content/cache/ -type f | head -20

## Contar archivos antes de eliminar
find wp-content/cache/ -type f | wc -l

## Eliminar archivos más antiguos de 30 días
find wp-content/cache/ -type f -mtime +30 -delete

Es la herramienta correcta para un directorio de cache y casi nunca la correcta para nada más, porque no pregunta antes ni deja deshacer después. El hábito que te salva es ejecutar ls sobre exactamente la misma ruta primero y borrar solo cuando el listado coincide con lo que tenías en la cabeza. Vigila sobre todo el final de la ruta, porque un espacio de más convierte un objetivo en dos, y el segundo suele ser el directorio padre. En un sitio con tráfico el plugin reconstruye la cache en la siguiente petición, de modo que el precio es una carga lenta y no una caída.

#8. Cómo copiar archivos entre servidores con rsync y scp

Cuando necesitas mover archivos entre servidores:

#rsync

## Sincronizar archivos al servidor remoto
rsync -avz --progress /local/path/ usuario@servidor:/remoto/path/

## Cómo sincronizar solo archivos cambiados por SSH en WordPress
rsync -avz --progress --update /local/ usuario@servidor:/remoto/

## Excluir archivos innecesarios
rsync -avz --exclude='node_modules' --exclude='.git' /local/ usuario@servidor:/remoto/

#scp para transferencias simples

## Copiar archivo al servidor
scp backup.sql usuario@servidor:/ruta/destino/

## Copiar archivo desde el servidor
scp usuario@servidor:/ruta/archivo.sql ./local/

La barra final en la ruta de origen significa “el contenido de esta carpeta”; sin ella acabas con uploads/uploads anidado. Y --delete refleja también los borrados, es decir, elimina en el destino todo lo que ya no existe en local: lanzado desde una copia local desactualizada, ese parámetro vacía la biblioteca de medios en lugar de sincronizarla. Por eso la primera pasada se hace siempre con -n, que enseña la lista sin tocar nada. rsync además tiene que estar instalado en los dos extremos, y cuando falta en el servidor el comando falla al instante en vez de degradarse a otra cosa.

#9. Cómo monitorizar CPU, memoria y procesos del servidor

#Uso de recursos en tiempo real

## Cómo ver procesos que consumen más recursos en el servidor WordPress
top

## Versión mejorada (si disponible)
htop

## Ver uso de memoria
free -h

## Ver uso de disco por partición
df -h

## Ver conexiones de red activas
netstat -tuln

#Identificar procesos PHP pesados

## Ver procesos PHP activos
ps aux | grep php

## Ver consultas MySQL lentas
mysqladmin -u root -p processlist

Estos comandos responden a una pregunta distinta de la del disco: no qué ocupa espacio, sino qué está consumiendo el procesador ahora mismo. Cuando veas varios procesos PHP fijos arriba en la lista, el culpable casi nunca es WordPress en sí, sino una consulta lenta o un cron que se solapa consigo mismo porque la ejecución anterior todavía no terminó. Comprueba esa hipótesis con wp cron event list antes de tocar el servidor. Y ten presente que en alojamiento compartido ves procesos de toda la máquina, así que una carga alta puede no tener nada que ver con tu sitio.

#10. Cómo crear alias y scripts de mantenimiento para WordPress

Crea aliases para comandos que usas frecuentemente:

## Agregar a ~/.bashrc o ~/.zshrc
alias wplog='tail -f wp-content/debug.log'
alias wpsize='du -h --max-depth=1 | sort -hr'
alias wpcache='rm -rf wp-content/cache/*'
alias wpdb='wp db export backup-$(date +%Y%m%d).sql'
alias wpcheck='wp core verify-checksums && wp plugin list --update=available'

#Script de mantenimiento automatizado

#!/bin/bash
## Script de mantenimiento diario de WordPress
echo "=== Mantenimiento WordPress $(date) ==="

## Respaldo de base de datos
wp db export /respaldos/db-$(date +%Y%m%d).sql
echo "Base de datos respaldada"

## Verificar integridad del core
wp core verify-checksums
echo "Core verificado"

## Listar actualizaciones disponibles
echo "=== Actualizaciones disponibles ==="
wp plugin list --update=available
wp theme list --update=available
wp core check-update

## Limpiar transients
wp transient delete --expired
echo "Transients limpiados"

## Optimizar base de datos
wp db optimize
echo "Base de datos optimizada"

echo "=== Mantenimiento completo ==="

Los alias son cómodos y también la forma más fácil de ejecutar en producción algo que creías estar ejecutando en pruebas. Deja que el nombre diga dónde actúa, y no lo abrevies tanto que se pueda escribir por accidente. Para cualquier script de mantenimiento, la regla es la misma que en el resto del artículo: primero el respaldo, después la operación, y una comprobación al final que falle de forma visible. Un script que borra y no verifica nada solo te informa de que se ejecutó, no de que funcionó.

#Cómo conectarse al MySQL del servidor por un túnel SSH

Los alojamientos gestionados cierran MySQL al exterior. El puerto 3306 solo responde en localhost, el cliente de escritorio se queda esperando hasta agotar el tiempo y en el panel solo queda phpMyAdmin. No necesitas un puerto abierto, necesitas un túnel.

#ssh -L

# Enlazar el puerto local 3307 con el MySQL del servidor, sin abrir shell remota
ssh -N -L 3307:127.0.0.1:3306 usuario@servidor

Deja esa terminal abierta y apunta TablePlus, DBeaver o el cliente mysql a 127.0.0.1:3307. -N significa “ningún comando remoto”: la sesión solo reenvía el tráfico. El mismo truco llega a todo lo que escucha solo en local en el servidor: Redis en el 6379, una aplicación de pruebas en el 8080, un endpoint que nunca debió ser público. Elige un puerto local que esté libre de verdad, porque ssh avisa de que la asociación falló y aun así mantiene la sesión abierta. Parece un túnel que funciona hasta que la primera consulta se queda colgada.

#Cómo cambiar el dominio de WordPress con WP-CLI search-replace

Después de una migración la base de datos sigue llena del dominio antiguo, y buena parte está dentro de arrays PHP serializados, donde cada cadena guarda su propia longitud. Un UPDATE ... REPLACE simple cambia el texto y deja la longitud mal, y a continuación los widgets, las opciones del tema y los diseños del page builder aparecen vacíos. WP-CLI entiende la serialización y te enseña lo que va a tocar antes de tocarlo.

#wp search-replace --dry-run

# Contar lo que cambiaría, sin escribir nada
wp search-replace 'https://staging.ejemplo.es' 'https://ejemplo.es' --dry-run --all-tables-with-prefix --report-changed-only

Recibes una tabla con el número de coincidencias por columna. Cuando las cifras cuadren con lo que esperas, repite el comando sin --dry-run. Añade --precise si el sitio tiene serialización anidada, porque fuerza el camino más lento por PHP en lugar del atajo por SQL, y --recurse-objects cuando hay objetos serializados de por medio. En cualquier caso haz antes wp db export: search-replace no tiene forma de deshacer.

#Cómo ejecutar WP-CLI en un servidor remoto desde su propio equipo

WP-CLI puede ejecutar un comando en otra máquina por SSH, así que no hace falta abrir antes una shell. El manual de WP-CLI describe el parámetro global --ssh con la forma [<scheme>:][<user>@]<host>[:<port>][<path>] (Running commands remotely):

wp [email protected]:2222/home/cliente/public_html plugin list

La ruta va justo después del puerto. Si indicas solo el servidor, el usuario pasa a ser tu nombre local, el puerto el 22 y la ruta la carpeta personal del usuario SSH. Un alias de ~/.ssh/config también sirve, de modo que wp --ssh=cliente-prod hereda el puerto y la clave de la sección sobre ese archivo. Para los proyectos a los que vuelves a menudo, registra alias en el wp-cli.yml del proyecto o en el ~/.wp-cli/config.yml global:

@prod:
  ssh: [email protected]/home/cliente/public_html
@staging:
  ssh: [email protected]/home/cliente/staging
@both:
  - @prod
  - @staging

Después, wp @prod core version consulta producción, y el grupo @both ejecuta wp @both core check-update en las dos instalaciones de una vez. La condición con la que tropieza la mayoría de los alojamientos compartidos: WP-CLI tiene que estar instalado en el servidor y accesible como wp en su $PATH. Una sesión SSH abierta de esta forma no lee ~/.bashrc, así que un wp definido ahí como alias no se encuentra. El manual propone colocar el ejecutable en $HOME/bin/wp. Por tu conexión solo pasan el comando y su salida, y eso es lo que hace tan cómodo lanzar el wp search-replace --dry-run de la sección anterior contra un sitio en producción.

#Qué hacer si el hosting solo permite SFTP

Algunos planes compartidos anuncian SSH y entregan SFTP, es decir, transferencia de archivos por el mismo protocolo pero sin shell al otro lado. Se descubre en el momento en que ssh usuario@host 'ls' responde exec request failed on channel 0. Nada de lo que en esta guía se ejecuta en el servidor sobrevive a eso: ni du, ni tar, ni WP-CLI, porque no hay ningún proceso donde puedan correr. La capa de transferencia sigue viva, así que sftp mueve archivos mejor que cualquier cliente con ventana (rsync no, porque necesita arrancar su propio proceso al otro lado), y el trabajo sobre la base de datos vuelve al navegador, a phpMyAdmin y a un plugin de copias. Antes de darlo por perdido, mira si el proveedor ofrece shell en otro puerto o la activa cuando se pide, porque en bastantes casos es un ajuste y no un límite del producto. Si de verdad no está en ese plan, tienes un argumento concreto para plantear un cambio, porque todos los flujos de trabajo anteriores te quedan cerrados.

#Resumen

La terminal SSH no muerde. Te permite trabajar a la velocidad del disco del servidor, no a la velocidad de tu conexión a internet. Comienza con ncdu y tail -f, no querrás volver a hacer clic con el ratón.

Los comandos esenciales para empezar:

1. du / ncdu - Análisis de espacio en disco
2. tail -f - Depuración en tiempo real
3. grep -r - Búsqueda de código
4. find + chmod - Corrección de permisos
5. tar - Respaldos rápidos
6. wp (WP-CLI) - Gestión completa de WordPress
7. rm -rf - Eliminación rápida (con precaución!)
8. rsync - Transferencia eficiente de archivos
9. top / htop - Monitorización de recursos
10. Aliases - Productividad automatizada

Conoce más sobre los servicios de desarrollo WordPress en WPPoland.