Cómo crear un PENDRIVE cifrado de nivel casi MILITAR para almacenamiento seguro
Con un aumento salvaje de las operaciones de ataque a sistemas que estamos viviendo en la actualidad, muchos motivados por el crecimiento del uso de la IA, te propongo que aprendas a preparar pendrives u otros dispositivos de almacenamiento, con un cifrado de nivel casi militar donde podrás salvar todo tipo de información y documentos imposibilitando su acceso en caso de pérdida o robo.
Este tutorial requiere algunos conocimientos de LINUX, ya que es el entorno habitual en el que se mueven los servidores en internet, incluido el tuyo. No tardaré en preparar un tutorial similar pero que te sirva para cifrar las unidades bajo Windows.
Además, este tutorial te llevará por el camino de la mejora de la seguridad de tus sistemas online mediante la creación de pares de claves pública-privada para el acceso seguro (o casi) a la terminal vía SSH.
Quizá, en un futuro pŕoximo, prepare este mismo tuto en formato de vídeo para el canal. Si prefieres vídeo, déjame un comentario en este blog o envíame un email.
Vamos al lío:
Parte 1: Crear y formatear un pendrive con LUKS2
Advertencia crítica: Los siguientes comandos borrarán irreversiblemente todos los datos del pendrive. Debes identificar correctamente el dispositivo (por ejemplo, /dev/sdb). Un error aquí podría destruir tu disco duro principal.
Paso 1: Identificar el dispositivo
Conecta el pendrive y lista los dispositivos de bloque para identificar su nombre.
lsblk
Busca tu pendrive por su tamaño (ej. 32G) y modelo. Supongamos que es /dev/sdb. Asegúrate de usar el dispositivo completo (/dev/sdb), no una partición (/dev/sdb1), para el formateo LUKS.
Paso 2: Crear el contenedor LUKS2
Usa cryptsetup con el tipo luks2. El sistema te pedirá que confirmes escribiendo YES en mayúsculas y luego establecerás una contraseña (passphrase) robusta.
sudo cryptsetup luksFormat --type luks2 /dev/sdb
Nota: El comando usa los parámetros de cifrado seguros por defecto (AES-XTS-Plain64 y Argon2id) .
Paso 3: Abrir el contenedor cifrado
Para poder crear un sistema de archivos dentro, primero debes "abrir" el contenedor. Le asignas un nombre (ej. pendrive_cifrado).
sudo cryptsetup open /dev/sdb pendrive_cifrado
Esto creará un nuevo dispositivo virtual en /dev/mapper/pendrive_cifrado.
Paso 4: Crear el sistema de archivos
Formatea el dispositivo mapeado con el sistema de archivos que prefieras (ext4 es una opción estándar y robusta en Linux).
sudo mkfs.ext4 /dev/mapper/pendrive_cifrado
Paso 5: Cerrar y usar
Para montarlo y usarlo, repite el paso 3 (abrir) y luego monta el dispositivo mapeado donde quieras. Para expulsarlo de forma segura, primero desmonta y luego cierra el contenedor.
Parte 2: Crear claves SSH y asegurar el servidor
Paso 1: Generar el par de claves (en tu máquina local)
El algoritmo recomendado actualmente es Ed25519 por su seguridad y rendimiento .
Ejecuta el comando y sigue las instrucciones (puedes pulsar Enter para la ubicación por defecto). Se te pedirá una passphrase; úsala para proteger tu clave privada en caso de robo
ssh-keygen -t ed25519 -C "tu_comentario_o_email"
Paso 2: Copiar la clave pública al servidor
La forma más sencilla es con ssh-copy-id, que añadirá tu clave pública al archivo authorized_keys del servidor de forma automática.
ssh-copy-id usuario@ip_del_servidor
Alternativa manual (si no tienes ssh-copy-id):
Puedes copiar el contenido de tu clave pública (~/.ssh/id_ed25519.pub) y pegarlo al final del archivo ~/.ssh/authorized_keys en el servidor. Asegúrate de que los permisos sean correctos (700 para .ssh y 600 para authorized_keys) .
Paso 3: Probar la conexión
Intenta conectarte por SSH. Si has puesto passphrase a la clave, te la pedirá; si no, entrarás directamente. No cierres esta sesión hasta haber completado el siguiente paso.
ssh usuario@ip_del_servidor
Mejorar la seguridad de SSH (endurecimiento)
Paso 4: Editar la configuración del servidor
En la sesión SSH que tienes abierta, edita el archivo de configuración del demonio SSH con permisos de superusuario.
sudo nano /etc/ssh/sshd_config
Paso 5: Aplicar los cambios de seguridad
Busca y modifica (o añade si no existen) las siguientes directivas. Esto es clave para forzar el uso de claves y evitar ataques de fuerza bruta :
PubkeyAuthentication yes: Asegura que la autenticación por clave pública esté habilitada.
PasswordAuthentication no: Desactiva el inicio de sesión por contraseña. Esto es lo que impide los ataques de fuerza bruta.
PermitRootLogin no: (Recomendado) Evita que el usuario root se conecte directamente por SSH.
Paso 6: Reiniciar el servicio y verificar
Guarda el archivo y reinicia el servicio SSH para aplicar los cambios.
En sistemas con systemd:
sudo systemctl restart sshd
Verificación crucial: Sin cerrar tu sesión actual, abre otra terminal e intenta conectarte de nuevo. Si entras sin que te pida la contraseña del usuario (solo la passphrase de la clave, si la tiene), todo funciona.
Si algo falla, puedes usar la sesión que dejaste abierta para corregir el archivo de configuración.
¡OJO: Ten en cuenta!
Si no verificas correctamente y cierras la sesión SSH original después de modificar la configuración, lo más probable es que te quedes completamente fuera de tu propio servidor y pierdas la capacidad de gestionarlo de forma remota.
Esto se debe a que las modificaciones en /etc/ssh/sshd_config pueden fallar por múltiples razones, y una vez que el servicio SSH no puede iniciarse o rechaza todas las conexiones, tu sesión SSH original es la única "puerta trasera" que puede rescatar la situación. Cerrarla equivale a bloquear tú mismo la última vía de rescate.
¿Qué situaciones específicas pueden ocurrir?
Según el tipo de error, las consecuencias se dividen principalmente en los siguientes dos tipos:
1. Error de sintaxis en el archivo de configuración, que impide el inicio de sshd
Si en el archivo de configuración escribes mal una palabra clave, ingresas un valor no compatible o dejas un carácter extraño, el servicio sshd fallará directamente al reiniciarse.
Consecuencia: El servicio SSH deja de ejecutarse por completo. En este momento, todos los intentos de conexión SSH (incluyendo el uso de claves) serán rechazados porque el puerto ni siquiera está escuchando. Si cierras la sesión activa que aún tienes abierta, nadie podrá iniciar sesión en el servidor.
2. Configuración lógica incorrecta, que te excluye a ti mismo
Este es un error más común y sutil. Por ejemplo, querías deshabilitar el inicio de sesión con contraseña, pero accidentalmente escribiste mal el nombre de usuario o no configuraste correctamente la ruta de la clave pública. En este caso, sshd puede iniciarse normalmente, pero rechazará tu inicio de sesión.
Consecuencia: Verás un mensaje como Permission denied (publickey). Dado que la autenticación por contraseña ya ha sido deshabilitada por ti, y la autenticación por clave tampoco funciona, te quedarás bloqueado fuera del sistema. En este momento, si aún conservas la sesión original, puedes iniciar sesión y corregirla; si la cierras, no podrás entrar.
Si realmente te quedas bloqueado fuera, ¿cómo rescatar?
La única opción real es salir corriendo en círculos mientras agarras tu pelo y sueltas grititos agónicos mientras sufres varios microinfartos...
NO, QUÉ VA =8-)
Necesitas usar el consola VNC o consola web proporcionada por el proveedor de servicios de hosting (no depende del servicio SSH, equivale a conectar directamente un monitor al servidor).
Los pasos de rescate suelen ser:
Inicia sesión en el panel de control del servidor e ingresa a la consola VNC (Remmina es una buena app y está disponible en todas las distros de linux).
Inicia sesión en el sistema con tu nombre de usuario y contraseña habituales (si no has deshabilitado el inicio de sesión por contraseña para este usuario).
Una vez dentro, modifica nuevamente /etc/ssh/sshd_config para corregir el error, o temporalmente cambia PasswordAuthentication de vuelta a yes para recuperar primero el acceso.
Ejecuta sudo sshd -t para confirmar que la configuración no tiene errores, luego sudo systemctl restart sshd para reiniciar el servicio.
Una vez que puedas conectarte normalmente usando una nueva ventana SSH, cierra la ventana de la consola.
Prueba en máquina virtual con un linux virtualizado antes de meterte en producción y me cuentas qué tal. Seguro que mejora bastante la seguridad de tus sistemas.