Candado de seguridad blanco sobre pedestal verde pastel

GPG para Sysadmins: Guía Definitiva para Cifrar Archivos en Linux

octubre 14, 2026 Alfonso Moreno | Sysadmin Senior 21 Visitas 13 min de lectura

GPG existe desde 1999 y sigue siendo la herramienta de cifrado de archivos más usada en el mundo Linux. La mayoría de los sysadmins la ven como “esa cosa que apt usa para verificar signatures” y nunca la exploran más allá. Esta guía documenta los usos reales: cifrado de backups offsite, firma de commits Git, autenticación SSH (GPG agent), y el intercambio seguro de secretos entre sysadmins de un equipo. También cubre el setup de gpg-agent con TTL, smart cards (YubiKey), y el workflow de revocation cuando perdés acceso a tu key.

Si quieres cifrar archivos de verdad y no solo “ponerles password al zip”, esta guía es para ti.

TL;DR — Lo que vas a tener al final

Tiempo de setup: 30-60 minutos para key funcional, 1-2 horas para YubiKey.
Requisitos: GnuPG 2.4+, máquina Linux con acceso a smart card (opcional).
Resultado: GPG key operativa, backups cifrados, firma de Git, opcionalmente YubiKey para 2FA.
Troubleshooting típico: gpg-agent no persiste entre sesiones, YubiKey no detectado. Solución: `gpgconf –reload all` + `pcscd`.

Por qué GPG sigue siendo relevante en 2026

Hay una idea casi cierta sobre todo: que el cifrado en servidores modernos se resuelve con TLS, SSH y vaults gestionados. Y en parte es cierto: para tránsito y secretos en reposo, ya no estás solo con GPG. Pero GPG sigue siendo la herramienta correcta cuando necesitas cifrar archivos concretos, firmar artefactos y verificar identidad fuera de banda: backups antes de subir a S3, releases que publicas, configuración que sale de un pipeline, secretos que viajas en un USB cifrado.

La familia OpenPGP está estandarizada en RFC 9580 (la revisión moderna del clásico RFC 4880), GnuPG 2.5.24 es la versión estable de referencia desde septiembre de 2026, y la serie 2.4 llegó a su fin de vida el 30 de junio de 2026 según el anuncio oficial del proyecto. Es software maduro, auditado y aburrido en el mejor sentido: hace lo que dice, sin sorpresas.

En esta guía vas a aprender a:

Crear tu par de claves GPG y entender qué estás generando realmente.
Cifrar archivos con passphrase (caso simple) y con clave pública (caso multi-destino).
Firmar y verificar artefactos (releases, backups, paquetes internos).
Automatizar GPG en scripts y pipelines sin que la passphrase bloquee tu sesión SSH.
Distribuir tu clave pública vía keys.openpgp.org y Web Key Directory.

Cuándo usar cifrado simétrico vs asimétrico

Antes de ejecutar comandos, entiende el modelo. La elección entre gpg -c y gpg -e depende de quién necesita descifrar el archivo. Si dudas, relee esta tabla:

Escenario	Método	Comando base	Quién descifra
Backup local que solo tú abres	Simétrico (passphrase)	`gpg -c archivo`	Quien conozca la passphrase
Archivo para otro sysadmin	Asimétrico (clave pública del destinatario)	`gpg -e -r email archivo`	Solo el destinatario con su clave privada
Backup que subes a S3 y quieres recuperar si pierdes la passphrase	Asimétrico (a tu propia clave)	`gpg -e -r tu-email archivo`	Solo tú con tu clave privada
Firma de un release público	Firma detached	`gpg --detach-sign archivo`	Quien tenga tu clave pública
Múltiples destinatarios	Asimétrico a varias claves	`gpg -e -r a@x -r b@y archivo`	Cualquiera de los destinatarios

El error clásico del principiante es mezclar ambos: cifra un backup con gpg -c usando una passphrase memorable y después asume que un compañero puede recuperarlo. No puede. Si quieres delegación, usa asimétrico.

Instala y verifica tu versión

En Debian y Ubuntu el paquete se llama gnupg; en Fedora y RHEL, también gnupg; en Arch, gnupg. Verifica qué tienes realmente antes de empezar, porque los flags cambian entre series.

# Versión y serie
gpg --version | head -3
# Esperado en 2026: 2.5.x estable, o 2.4.x en distribuciones conservadoras
# Si ves 2.0.x o 1.4.x: actualiza antes de seguir
gpg --version | awk '/gpg (GnuPG)/ {print $3}'

Si tu distro todavía trae la serie 2.4.x no pasa nada para esta guía: los comandos siguen funcionando. La diferencia relevante con 2.5 está en características nuevas (mejoras en smartcards y manejo de claves de gran tamaño) que no vas a necesitar para cifrar backups.

Tu primera clave GPG: paso a paso

El comando gpg --full-generate-key abre un asistente interactivo. La opción --quick-gen-key genera una clave RSA de 3072 bits con un solo paso, ideal para servidores y automatización. Para una workstation donde sí quieres curva elíptica (más rápida y con claves más cortas), usa el flujo completo.

# Flujo rápido: RSA 3072 bits, sin passphrase (NO recomendado, ve abajo)
# gpg --quick-gen-key "Tu Nombre <[email protected]>" default default 0
# Flujo recomendado: RSA 4096 + passphrase fuerte + fecha de expiración
gpg --full-generate-key

El asistente te preguntará:

Tipo de clave: elige (1) RSA and RSA, (2) DSA and ElGamal o (9) ECC (sign and encrypt). Para 2026, (9) con curva ed25519/cv25519 es la mejor opción: claves más pequeñas, mismas garantías criptográficas.
Tamaño: 4096 bits si elegiste RSA; las ECC no preguntan tamaño (la curva define el nivel).
Expiración: pon una fecha (2y por ejemplo). Una clave sin expiración es cómoda pero te bloquea si algún día la quieres revocar formalmente.
Nombre real + email + comentario: completa los tres. El email debe ser real, porque será el identificador principal de tu clave.
Passphrase: nunca vacía. Usa un gestor de contraseñas (KeePassXC, pass, Bitwarden) para almacenarla; sin passphrase cualquier robo del llavero GPG abre todos tus archivos cifrados.

Una vez generado, lista tus claves para confirmar:

# Claves públicas que posees
gpg --list-keys
# Claves privadas que posees
gpg --list-secret-keys
# Tu fingerprint (lo que realmente identifica tu clave)
gpg --list-keys --fingerprint tu-email@domain

El fingerprint es lo que importa cuando publiques o importes claves. El key ID corto (8 caracteres hex) es ambiguo y se considera inseguro desde 2019; siempre trabaja con el fingerprint completo (40 caracteres hex).

Cifrar archivos con passphrase (caso simple)

Para un dump de base de datos que solo tú vas a recuperar, el cifrado simétrico es el camino más simple y robusto. El comando gpg -c usa AES-256 por defecto en GnuPG moderno.

# Cifrar un archivo con passphrase
gpg -c backup-2026-10-14.sql
# Te pedirá la passphrase dos veces para confirmar.
# Genera backup-2026-10-14.sql.gpg (binario)
# Descifrar cuando lo necesites
gpg -d backup-2026-10-14.sql.gpg > backup-2026-10-14.sql
# O descifrar in-place (escribe el archivo original)
gpg backup-2026-10-14.sql.gpg
# Cifrar con salida ASCII (útil para adjuntar en email, copiar-pegar)
gpg -c --armor backup-2026-10-14.sql
# Salida: backup-2026-10-14.sql.asc

Para un sysadmin, el patrón real es combinar esto con tu pipeline de backups y subir el .gpg a S3 sin la passphrase:

#!/usr/bin/env bash
# backup_encrypt.sh — cifra un dump antes de subirlo
set -euo pipefail
DUMP="/var/backups/db-$(date +%Y%m%d).sql"
KEYFILE="/root/.backup-passphrase"   # chmod 600
gpg --batch --yes --passphrase-file "$KEYFILE" 
    --cipher-algo AES256 --compress-algo zlib 
    -c "$DUMP"
# Borra el original, conserva solo el cifrado
shred -u "$DUMP"
# Ahora sube db-YYYYMMDD.sql.gpg a S3
aws s3 cp "${DUMP}.gpg" s3://mi-bucket/backups/

Las opciones --batch y --passphrase-file son obligatorias para que el comando no se quede esperando input interactivo. shred -u sobrescribe el archivo original antes de borrarlo; en SSD no es garantía absoluta (por el wear leveling), pero en disco rotado es la opción adecuada.

Cifrar para otro sysadmin: intercambio de claves + cifrado asimétrico

Cuando el archivo viaja a otra persona (o a otro servidor de tu propia flota), el flujo es: importas su clave pública, cifras con ella, y solo el destinatario puede descifrar con su clave privada.

# 1. Importar clave pública del destinatario desde un archivo
gpg --import clave-publica-colega.asc
# O desde keys.openpgp.org directamente
gpg --keyserver hkps://keys.openpgp.org --recv-keys ABC123DEF456...
# 2. Verificar que la importaste (mira el fingerprint)
gpg --list-keys
# 3. Cifrar el archivo dirigido a su email
gpg -e -r [email protected] informe-q3.pdf
# Genera informe-q3.pdf.gpg
# Solo [email protected] puede descifrarlo

Antes de confiar en una clave pública ajena, verifica el fingerprint fuera de banda: por teléfono, en persona, o con un hash publicado en su sitio web. Sin esta verificación, alguien podría hacerte creer que su clave es la de tu colega y redirigir tus archivos cifrados. El fingerprint es la única identidad real.

Para publicar tu propia clave pública, expórtala en ASCII:

# Exportar tu clave pública en formato ASCII
gpg --export --armor tu-email@domain > mi-clave-publica.asc
# O el binario, más compacto
gpg --export tu-email@domain > mi-clave-publica.gpg

El archivo .asc es texto plano: lo puedes pegar en un email, subirlo a tu web, o servirlo en una URL. La clave privada nunca sale de tu máquina; si la pierdes, pierdes todo lo cifrado hacia ella.

Firmar y verificar artefactos

Firmar es el otro uso crítico de GPG para sysadmins. Cuando publicas un release de tu software interno, un tarball de configuración, o un instalador, la firma le permite al destinatario verificar que el archivo no fue modificado después de que tú lo firmaste.

# Firma detached (archivo .sig separado, recomendado)
gpg --detach-sign release-v1.2.3.tar.gz
# Genera release-v1.2.3.tar.gz.sig
# Verificar la firma
gpg --verify release-v1.2.3.tar.gz.sig release-v1.2.3.tar.gz

El mensaje de salida dirá Good signature from "Tu Nombre <[email protected]>" si la firma corresponde al archivo y a la clave. Cualquier otra línea (en particular BAD signature o WARNING: This key is not certified) significa que algo no cuadra y debes tratar el archivo como no confiable.

Para verificar la firma de un release de un proyecto open source (ej. el binario de LinuxCNC, las imágenes de Debian, los tarballs de GnuPG mismo), el flujo es simétrico: descargas la clave del maintainer, la importas, y verificas:

# Traer clave del maintainer
gpg --keyserver hkps://keys.openpgp.org --recv-keys MAINTAINER_FINGERPRINT
# Verificar el tarball
gpg --verify gnupg-2.5.24.tar.bz2.sig gnupg-2.5.24.tar.bz2

El warning This key is not certified with a trusted signature es normal y no es problema: significa que no has marcado la clave como trusted en tu llavero local. Solo BAD signature es motivo para descartar el archivo.

Automatización en CI/scripts: pinentry-mode loopback

El obstáculo más común al automatizar GPG es el pinentry: cuando firmo o descifro en un script, GnuPG intenta abrir una ventana emergente para pedir la passphrase. En una sesión SSH sin X11, o en un job de CI, esa ventana nunca aparece y el script se queda colgado.

La solución es configurar el agente para permitir entrada de passphrase por loopback (stdin):

# ~/.gnupg/gpg-agent.conf
allow-loopback-pinentry
default-cache-ttl 3600
max-cache-ttl 7200

Y en el script, usa --pinentry-mode loopback cuando pases la passphrase por archivo:

#!/usr/bin/env bash
# sign_release.sh — firma un release en CI
set -euo pipefail
KEYFILE="/run/secrets/release-signing-passphrase"
TARBALL="$1"
gpg --batch --pinentry-mode loopback 
    --passphrase-file "$KEYFILE" 
    --detach-sign "$TARBALL"
echo "Firmado: ${TARBALL}.sig"

Recargar el agente después de cambiar gpg-agent.conf:

gpgconf --kill gpg-agent
# O alternativamente
gpg-connect-agent reloadagent /bye

Importante: allow-loopback-pinentry permite que cualquier proceso local pida la passphrase sin ventana. Úsalo solo en cuentas dedicadas a CI o a firma automatizada. En tu workstation personal déjalo desactivado: el pinentry gráfico normal es la interfaz correcta.

Gestión de claves: backup, revocación, expiración

El escenario de pesadilla: tu laptop muere, no tienes backup de la clave privada, y tienes un backup cifrado de 3 TB en S3 que ya no puedes abrir. Esto se evita con tres hábitos.

Backup del llavero (ejecutar una vez, guardar fuera de la máquina):

# Crear un archivo con tu clave privada + pública
gpg --export-secret-keys --armor tu-email@domain > clave-privada-backup.asc
gpg --export --armor tu-email@domain >> clave-privada-backup.asc
# Cifra ese backup con una passphrase larga que puedas recordar (o guárdalo en tu gestor)
gpg -c --cipher-algo AES256 clave-privada-backup.asc
# Borra el original sin cifrar
shred -u clave-privada-backup.asc
# Copia clave-privada-backup.asc.gpg a un lugar offline
# (USB cifrado, papel en una caja fuerte, etc.)

Certificado de revocación: prepáralo antes de necesitarlo, porque una vez comprometida la clave ya no podrás generarlo:

# Genera el certificado (output: revocacion.asc)
gpg --gen-revoke tu-email@domain > revocacion.asc
# Guárdalo en el mismo lugar offline que tu backup
# NO lo publiques hasta que realmente pierdas la clave

Renovar antes de expirar: si tu clave tiene expiración a 2 años, renueva la expiración un mes antes. Una clave expirada no rompe nada de lo ya cifrado, pero deja de poder firmar cosas nuevas.

# Extender la expiración 2 años más
gpg --edit-key tu-email@domain expire
# En el prompt: 2y
# Confirmar con "save"
# Re-publicar tu clave actualizada en keyservers
gpg --keyserver hkps://keys.openpgp.org --send-keys TU_FINGERPRINT

Distribuir tu clave: keys.openpgp.org y Web Key Directory

El ecosistema OpenPGP tiene dos piezas modernas para que otros encuentren tu clave: el keyserver keys.openpgp.org (sucesor de los keyservers SKS deprecados) y Web Key Directory (WKD), que permite descubrir claves por dominio.

Subir tu clave al keyserver principal:

# Subir al keyserver moderno
gpg --keyserver hkps://keys.openpgp.org --send-keys TU_FINGERPRINT
# Verificar que está indexada
gpg --keyserver hkps://keys.openpgp.org --search-keys tu-email@domain

WKD es más elegante: cuando alguien con un cliente OpenPGP moderno intenta enviarte algo cifrado, su cliente busca automáticamente en https://tu-dominio.com/.well-known/openpgpkey/.... Para activarlo en tu dominio:

# Exportar clave en formato WKD
gpg --export-options export-minimal --armor --export tu-email@domain > key.asc
# Subir a tu hosting en el path WKD (advanced method)
# https://tu-dominio.com/.well-known/openpgpkey/hu/<hash>
# O usar el servicio gestionado de keys.openpgp.org (más simple)
# https://keys.openpgp.org/about/usage-wkd/

Si tu dominio tiene la clave en WKD, cualquier usuario de ProtonMail, Thunderbird con Enigmail, o clientes compatibles puede cifrar para ti sin que tengas que enviarles manualmente tu clave pública.

Errores comunes y troubleshooting

Estos son los problemas reales que vas a encontrar, no el manual ideal:

“gpg: can’t connect to the agent”: el agente no está corriendo. gpgconf --launch gpg-agent lo arranca.
“Inappropriate ioctl for device” al pedir passphrase: no hay TTY disponible. O bien abres una terminal interactiva, o usas --pinentry-mode loopback --passphrase-file en scripts.
“No se ha encontrado dato OpenPGP válido” al importar: el archivo no es una clave, o está corrupto. Verifica con file clave.asc que diga PGP public key block.
“WARNING: unsafe permissions on homedir”: tu ~/.gnupg tiene permisos demasiado abiertos. chmod 700 ~/.gnupg y chmod 600 ~/.gnupg/*.
Olvidaste la passphrase: sin backup del llavero, no hay recuperación. Por eso el paso anterior es no-negociable.
“Key expired” en algo que firmaste ayer: la firma no expira, pero la clave sí. Renueva la expiración y re-firma si quieres que el destinatario verifique con una clave vigente.

Resumen

GPG no es la herramienta más moderna, pero sí la más portátil: el mismo cifrado abre en Debian, en macOS, en Windows con Gpg4win, en un contenedor Alpine sin systemd, y en un script de CI en GitHub Actions. Para sysadmins eso vale más que cualquier alternativa de moda.

Lo mínimo que necesitas del día uno:

Una clave ECC ed25519 con passphrase fuerte y expiración a 2 años.
Un backup offline de la clave privada cifrado con AES-256.
Un certificado de revocación guardado en el mismo lugar.
Tu clave pública publicada en keys.openpgp.org y en WKD de tu web.
gpg -c para backups locales, gpg -e -r para enviar a otros, gpg --detach-sign para artefactos.

Con eso resuelves el 95% de los casos que un sysadmin enfrenta. El 5% son Yubikeys, smartcards y Air-Gapped signing, que dan para otra guía.

Preguntas frecuentes

¿Por qué GPG para Sysadmins: Guía Definitiva para Cifrar Archivos en Linux es relevante para sysadmins Linux?

Forma parte del flujo diario de administración. Los conceptos explicados se aplican directamente a servidores en producción y resuelven problemas reales que enfrentan sysadmins hispanohablantes.

¿Qué necesito para empezar con GPG para Sysadmins: Guía Definitiva?

Distribución Linux actualizada (Debian, Ubuntu, RHEL, Fedora o Arch), acceso root, y conexión a internet. Para producción: entorno de staging separado antes de aplicar cambios.

¿Cuáles son los errores más comunes con GPG para Sysadmins: Guía Definitiva?

Los tres más frecuentes: (1) saltar la lectura de logs, (2) aplicar cambios directos en producción sin probar, (3) olvidar permisos y ownership. La documentación y un plan de rollback siempre.

¿Cuándo usar GPG para Sysadmins: Guía Definitiva y cuándo una alternativa?

Esta solución es ideal para el caso descrito. Alternativas como Docker, Ansible o configuración manual pueden ser mejores según contexto: portabilidad, escala y reproducibilidad son los factores clave.

¿Cómo migro desde una configuración previa a GPG para Sysadmins: Guía Definitiva?

Documentar el estado actual, probar la nueva configuración en staging, validar funcionalmente, y aplicar en producción con rollback plan listo. Los posts de SoyLinux incluyen troubleshooting para los problemas más comunes.