Autenticación en Linux: Cómo Funciona y Por qué las Contraseñas son Peores que las Claves

Este artículo analiza los procesos de autenticación y cómo el sistema verifica la autenticidad del usuario. Se comparan las contraseñas tradicionales y las claves SSH, explicando por qué una de ellas es un punto débil. También se configura un servidor para un funcionamiento seguro.

Autenticación y Autorización

En las distribuciones modernas de Linux, la verificación de las credenciales del usuario está a cargo del subsistema PAM (Pluggable Authentication Module), un mecanismo flexible que admite diferentes métodos de autenticación. Por ejemplo, al iniciar sesión, la contraseña introducida por el usuario puede verificarse localmente (archivos /etc/passwd y /etc/shadow), o con la ayuda de servicios externos (LDAP, claves SSH, etc.). La elección depende de la configuración de PAM y de las preferencias del administrador del sistema. Una vez superada la verificación, se establece una sesión para el usuario con los permisos correspondientes.

Es importante diferenciar dos conceptos similares pero distintos:

• Autenticación: Es el proceso de confirmar la identidad del usuario. El sistema verifica que el usuario es realmente quien dice ser. Para ello se utilizan credenciales, como un par de nombre de usuario y contraseña o una clave criptográfica.
• Autorización: Es el proceso de otorgar permisos de acceso después de una autenticación exitosa. El sistema decide qué puede hacer el usuario: qué archivos puede leer, qué comandos puede ejecutar, etc., estableciendo permisos y restricciones.

Este artículo se centra principalmente en la autenticación: cómo el usuario confirma su identidad al iniciar sesión (con contraseña o con clave).

Tipos de Autenticación

Linux admite varios métodos de autenticación. Analizaremos dos de los más comunes:

Autenticación por Contraseña

La autenticación por contraseña es el método clásico de inicio de sesión. El usuario se identifica con su nombre de usuario y confirma su identidad conociendo la contraseña secreta. Tanto en el trabajo local como en el acceso remoto, el proceso de autenticación por contraseña es prácticamente idéntico. La única diferencia es la interfaz para ingresar las credenciales: puede ser un formulario GUI o una terminal. En cualquier caso, el sistema verifica la autenticidad del usuario mediante la combinación de nombre de usuario y contraseña y lo autoriza.

En Debian y distribuciones derivadas, como Ubuntu, las cuentas de usuario se almacenan en el archivo /etc/passwd, y los hashes de las contraseñas en el archivo protegido /etc/shadow. Solo los procesos privilegiados (ejecutados como root) tienen acceso directo a este último. Sin embargo, ni siquiera ellos pueden ver las contraseñas, solo sus hashes.

Un módulo PAM especial transforma irreversiblemente la contraseña introducida y compara el resultado con el hash almacenado en /etc/shadow. El algoritmo y la “sal” utilizados también se indican en la línea con el hash. En las distribuciones modernas de Linux, normalmente se usa SHA-512 con “sal” en lugar del obsoleto DES/MD5. De este modo, la verificación se realiza de forma segura: las contraseñas reales no se transmiten ni se almacenan en texto plano.

Si el hash de la contraseña introducida coincide con el hash registrado para el nombre de usuario, el proceso de autenticación se considera superado. El usuario obtiene acceso al sistema con los permisos especificados en su cuenta, es decir, se le autoriza.

La autenticación por contraseña puede ser local o remota. En este último caso, normalmente se utiliza el protocolo SSH (Secure Shell). Su mecanismo puede utilizarse no solo para la autenticación por contraseña, como veremos más adelante. En las distribuciones basadas en Debian, el servidor OpenSSH permite, por defecto, el inicio de sesión con contraseña para todos los usuarios, excepto posiblemente para el usuario root. El parámetro PasswordAuthentication en el archivo /etc/ssh/sshd_config controla esta opción: el valor yes permite la autenticación por contraseña, no la prohíbe.

Lee también: Mejores Prácticas de Seguridad para Mitigar Ataques SSH

El protocolo SSH cifra todo el tráfico, por lo que la contraseña se transmite al servidor de forma segura. El demonio sshd del servidor descifra la contraseña recibida. Luego, el módulo PAM calcula el hash y lo compara con la entrada en /etc/shadow.

Las contraseñas tienen varios inconvenientes importantes:

• Las contraseñas se pueden descifrar mediante prueba y error: Los usuarios suelen elegir contraseñas fáciles de recordar, como palabras comunes o combinaciones de números. Los atacantes utilizan diccionarios y programas de fuerza bruta para intentar descifrarlas.
• Las contraseñas complejas y únicas son difíciles de recordar: Las recomendaciones de seguridad exigen contraseñas largas y con caracteres aleatorios, pero es difícil memorizar muchas de esas contraseñas. A menudo se escriben en papel o en lugares inseguros.
• Reutilización de contraseñas: Usar la misma contraseña en varios servicios es una práctica peligrosa pero común. La vulneración de una contraseña en un servicio pone en peligro las cuentas de otros servicios que utilizan la misma contraseña. Esto es especialmente crítico para los servidores. También se le conoce como “Credential Stuffing“.
• Las contraseñas se pueden averiguar o interceptar: Las contraseñas son un secreto que el usuario debe introducir manualmente y que puede ser visto por otros, robado con un keylogger o un virus.
• Gestión compleja: Gestionar contraseñas en muchos servidores es difícil. El administrador debe guardar una lista de contraseñas complejas, cambiarlas periódicamente y controlar su caducidad. Un solo error compromete la seguridad.

En los sistemas modernos, la autenticación por contraseña se considera el método menos seguro y requiere medidas adicionales para reducir los riesgos.

Autenticación SSH: Qué es y cómo funcionan las claves SSH

SSH (Secure Shell) es un protocolo de red para el acceso remoto seguro a un sistema. Proporciona el cifrado de la conexión y la autenticación de ambas partes. Permite conectarse a un servidor remoto y ejecutar comandos en una terminal como si se estuviera utilizando una conexión local en la misma máquina.

Funciona con un modelo cliente-servidor: en el nodo remoto debe ejecutarse un demonio SSH (servicio sshd) que escucha un puerto de red (normalmente el 22) y espera conexiones entrantes. El usuario utiliza un cliente SSH, que inicia la conexión, realiza la autenticación y cifra y descifra los datos.

OpenSSH es la implementación más popular de SSH en Linux. En las distribuciones basadas en Debian, el cliente OpenSSH ya está instalado. Para implementar el servidor, basta con instalar el paquete openssh-server; el servicio se iniciará automáticamente y podrá aceptar conexiones SSH entrantes. La configuración del servidor se almacena en el archivo /etc/ssh/sshd_config, donde se especifican los parámetros de autenticación, los protocolos de cifrado utilizados y otras configuraciones.

Para conectarse mediante SSH, el usuario introduce un comando del tipo:

ssh <usuario>@<host>

A continuación, se realiza el proceso de autenticación: mediante contraseña o mediante claves. El primer método ya se ha descrito anteriormente, junto con sus inconvenientes. El segundo método, la autenticación mediante claves SSH, permite iniciar sesión en el servidor sin introducir una contraseña, mediante un par de claves criptográficas previamente generadas: una clave privada y una clave pública.

El principio de funcionamiento de las claves SSH se basa en el cifrado asimétrico. La clave privada cifra los datos, y solo la clave pública asociada puede realizar la transformación inversa.

• La clave privada se almacena en el equipo local del usuario, no se divulga y nunca se transmite por la red.
• La clave pública no es secreta y puede transmitirse libremente por la red; se copia en el servidor de destino y normalmente se guarda en la carpeta del usuario en el servidor, en un archivo llamado ~/.ssh/authorized_keys.

Durante la conexión SSH, el servidor envía al cliente una cadena aleatoria (reto), que el cliente firma con su clave privada y envía de vuelta. El servidor verifica la firma utilizando la clave pública. Si la firma es correcta, se concede el acceso; de lo contrario, se rechaza. De este modo, se confirma la posesión de la clave privada sin transmitir ningún dato secreto por la red. No se necesita ninguna contraseña.

Se recomienda que cada administrador o proceso tenga su propio par de claves. En el archivo authorized_keys del servidor se pueden registrar varias claves públicas, una para cada usuario autorizado. De este modo, en caso de que se vea comprometida alguna clave, solo hay que revocarla.

Si es necesario, las claves SSH se pueden complementar con una protección adicional. Un ejemplo es restringir el acceso solo desde ciertas direcciones IP. Otra opción es añadir la autenticación de dos factores, ya que el protocolo SSH permite solicitar simultáneamente una clave y un código de un solo uso, obtenido, por ejemplo, mediante el módulo PAM de Google Authenticator.

¿Qué es mejor: contraseñas o claves SSH?

Analicemos los argumentos principales a favor de las claves.

Inmejorable resistencia al hackeo

Una contraseña de 8 a 10 caracteres puede ser descifrada relativamente rápido. Esto se hace mediante prueba y error o con un diccionario, especialmente si la contraseña es común. Una clave SSH, en cambio, es una secuencia de cientos de caracteres aleatorios, generalmente de 2048 o 4096 bits de longitud. La longitud y la entropía de estas claves superan en órdenes de magnitud incluso a las contraseñas más complejas.

Un ataque de fuerza bruta contra todas las claves SSH posibles es imposible incluso con los ordenadores más potentes actuales. De hecho, esta tarea requeriría millones de años de cálculo. En consecuencia, al prohibir el acceso mediante contraseña a favor de las claves, se elimina la posibilidad de este tipo de intrusión en el servidor. Los numerosos bots que atacan constantemente los servidores a través de SSH simplemente no podrán hacer nada: es imposible descifrar una clave, y no tendrán ni un solo intento para adivinar la contraseña.

Confidencialidad de la clave privada

Una ventaja significativa de las claves SSH es que la clave privada nunca abandona el equipo del usuario ni se transmite por la red. Es imposible robarla a través de la red. Incluso interceptando el tráfico SSH, que además está encriptado, un atacante no obtendrá ninguna información útil sobre la clave privada.

En el servidor solo se almacena la clave pública, cuya divulgación no supone riesgo de compromiso; solo se utiliza para verificar las llamadas y las respuestas. Es como “la cerradura de una puerta”: sin la clave privada, “no se puede abrir”. Al usar una contraseña, aunque SSH cifra la conexión, todavía son posibles ataques en el lado del cliente, como la instalación de keyloggers o simplemente mirando por encima del hombro.

Resistencia a la vulneración del servidor y a las fugas de datos

Un atacante puede comprometer un servidor donde se almacenan los hashes de las contraseñas; por ejemplo, puede obtener derechos de root y copiar el archivo /etc/shadow. Entonces, puede intentar descifrar las contraseñas sin conexión, probando combinaciones y comparando el hash resultante. Al usar claves, este ataque es inútil: no hay secretos en el servidor que se puedan usar para descifrar, ni tampoco hay una clave privada.

La vulneración de un servidor no proporciona al atacante herramientas para acceder directamente a otros nodos del usuario. La clave privada no se almacena de forma centralizada en ningún lugar y no puede filtrarse con otros datos. Por lo tanto, las filtraciones de bases de datos de contraseñas o el reuso de contraseñas (ataques de reutilización) no amenazan al sistema donde el acceso se realiza mediante claves.

Eliminación del factor humano

No es necesario recordar la clave, no se puede elegir una “demasiado simple” por casualidad. El usuario no podrá establecer una clave SSH trivial, como podría inventar una contraseña débil como “12345”. Desaparece el riesgo de usar combinaciones fáciles de adivinar o débiles.

Comodidad, flexibilidad y automatización

Con las claves SSH, puedes usar un par de claves para acceder a diferentes servidores propios (o generar un par separado para diferentes grupos de máquinas), lo que resulta mucho más cómodo que gestionar muchas contraseñas únicas para cada recurso. No es necesario introducir la contraseña cada vez que te conectas: la autenticación se realiza automáticamente.

La comodidad es especialmente notable en el caso de conexiones frecuentes o del uso de scripts automatizados y sistemas de orquestación. Por ejemplo, Ansible y Terraform utilizan claves para acceder a los servidores sin intervención humana. Este enfoque es más seguro que almacenar contraseñas en scripts en texto plano.

Otra ventaja de comodidad: cuando un empleado deja la empresa, basta con eliminar su clave pública de todos los servidores, en lugar de tener que reemplazar laboriosamente muchas contraseñas.

Ventaja conceptual: posesión frente a conocimiento

Desde el punto de vista de la teoría de la protección, las contraseñas pertenecen a los secretos basados en el conocimiento, mientras que las claves pertenecen a la posesión. Estas últimas se consideran más seguras: para comprometer una clave, el atacante debe apoderarse del propio soporte: el archivo de la clave privada. La contraseña, en cambio, se puede averiguar, interceptar o descifrar de forma remota.

Por supuesto, el ideal es combinar métodos. Por ejemplo, puedes usar una clave privada en un token de hardware junto con un PIN o en combinación con un código de un solo uso. Sin embargo, en el contexto de la elección “contraseña o clave”, esta última gana en todos los aspectos.

Conclusión

La autenticación SSH mediante claves, con un enfoque correcto, prácticamente carece de los inconvenientes de las contraseñas. Las claves SSH son inequívocamente más seguras y preferibles para el trabajo remoto. El único inconveniente relativo es que a los principiantes puede parecerles compleja la configuración inicial. Es necesario generar claves y saber dónde se ubican y cómo se utilizan. Sin embargo, existen herramientas y prácticas que hacen que la gestión de claves sea cómoda y centralizada.

A continuación, veremos las estadísticas de ataques que confirman las debilidades de las contraseñas, y también hablaremos del almacenamiento de claves secretas mediante un gestor especial.

Las contraseñas siguen utilizándose por razones históricas y por su aparente simplicidad. Sin embargo, desde el punto de vista de la protección del sistema, son significativamente inferiores a las claves criptográficas. Estas últimas, con un manejo adecuado, eliminan el principal vector de ataque: adivinar o robar la contraseña, y de este modo aumentan considerablemente la seguridad general de la infraestructura.

Estadísticas desalentadoras

Las estadísticas de incidentes de seguridad informática confirman una vez más la debilidad de las contraseñas como medida de protección.

El primer ataque mediante la prueba de contraseñas se observa a los 10-15 minutos de conectar un servidor recién desplegado a la red. A continuación, los ataques continúan constantemente, escaneando la máquina en busca de puertos SSH abiertos.

Al año se registran decenas de millones de intentos de acceso. La empresa Rapid7 realizó un estudio en honeypots SSH y RDP y proporcionó datos de 2021-2022. Se identificaron más de 216 000 direcciones IP únicas de atacantes y más de 512 000 contraseñas utilizadas en estos ataques. La gran mayoría de las contraseñas son comunes, incluso recogidas en diccionarios especiales. Entre las cinco primeras se encuentran: 123456, nproc, test, qwerty y password; es decir, valores francamente débiles.

Los datos recogidos indican que los atacantes confían en la existencia de contraseñas triviales o predeterminadas, y con frecuencia justifican sus expectativas.

El 81 % de los accesos no autorizados a cuentas en 2022 se debieron a contraseñas débiles, reutilizadas o robadas. Esto se indica en el informe de LastPass. En otras palabras, ocho de cada diez ataques exitosos a sistemas de información, de alguna manera, explotaron vulnerabilidades relacionadas con las contraseñas. Pueden ser robos mediante phishing, filtraciones de bases de datos de contraseñas, prueba de combinaciones simples o el uso de contraseñas robadas de otros servicios.

Dos tercios de los ataques a servicios en la nube están relacionados con credenciales vulnerables: otra señal preocupante. La causa es la misma: la falta de contraseña o una contraseña débil, según los datos de Google Cloud de la segunda mitad de 2024. Las contraseñas siguen siendo el “eslabón débil” a través del cual los atacantes obtienen acceso inicial antes de desarrollar el ataque.

Todos los datos indican inequívocamente que confiar únicamente en la protección mediante contraseña es extremadamente arriesgado. La seguridad es especialmente importante para los servidores, que siempre están disponibles en la red y son un objetivo constante. Al mismo tiempo, prácticamente no se producen casos de compromiso de SSH al usar solo claves, si se cumplen las reglas básicas:

• Clave compleja y algoritmo moderno.
• Protección de la clave privada.
• Desactivación del acceso mediante contraseña.

Las estadísticas de ataques confirman que el cambio a la autenticación mediante claves criptográficas reduce drásticamente la probabilidad de un ataque.

Configuración del acceso mediante clave SSH

En las distribuciones basadas en Debian, el servidor OpenSSH admite la autorización mediante claves de forma predeterminada (la directiva PubkeyAuthentication yes está activada). Para configurar el acceso mediante clave SSH, es necesario generar una clave e instalar la clave pública en el servidor. A continuación se muestra el procedimiento general:

1. Generación del par de claves en el cliente. En la terminal del usuario en el equipo local desde el que se realizará el acceso, ejecuta el comando de generación de claves. Por ejemplo, para RSA de 3072 bits (valor predeterminado para OpenSSH), el comando será el siguiente:

ssh-keygen -t ed25519 -C "Comentario (opcional)"

Por defecto, se te propondrá la ruta para guardar ~/.ssh/id_ed25519. Puedes cambiarla especificando la ruta relativa al directorio de inicio; por ejemplo:

Enter file in which to save the key (/home/alex/.ssh/id_ed25519): .ssh/my_key 

Además, si lo deseas, puedes introducir una frase de contraseña para proteger la clave. Tras ejecutar el comando, aparecerán dos archivos: la clave privada y la clave pública: ~/.ssh/my_key y ~/.ssh/my_key.pub.

2. Instalación de la clave pública en el servidor. La forma más sencilla de hacerlo es mediante la utilidad ssh-copy-id, si todavía es posible acceder mediante contraseña. Por defecto, la utilidad intenta copiar la primera clave que encuentra; normalmente, ~/.ssh/id_rsa.pub o ~/.ssh/id_ed25519.pub.

Si hay varias claves, es necesario indicar cuál de ellas utilizar. Copiaremos la clave de nuestro ejemplo: my_key.pub.

ssh-copy-id i ~/.ssh/my_key.pub <nombre_de_usuario>@<dirección_del_servidor> 

La utilidad solicitará la contraseña actual del usuario en el servidor y, a continuación, copiará automáticamente el contenido de my_key.pub en el archivo ~/<nombre_de_usuario>/.ssh/authorized_keys del servidor. Si el directorio .ssh o el archivo authorized_keys no existen, se crearán.

También puedes copiar la clave pública manualmente. Para ello, guárdala en una ubicación adecuada del servidor y, a continuación, añádela al contenido de ~/.ssh/authorized_keys. Por ejemplo, puedes utilizar la utilidad scp (Secure Copy):

scp ~/.ssh/my_key.pub <nombre_de_usuario>@<dirección_del_servidor>:~/ cat ~/my_key.pub >> ~/.ssh/authorized_keys 

Por supuesto, para realizar esta operación, el usuario debe tener acceso al servidor y los derechos correspondientes.

3. Comprobación del acceso mediante clave. Comprobemos el funcionamiento de SSH; intentemos conectarnos al servidor, especificando la clave:

ssh -i ~/.ssh/my_key.pub <nombre_de_usuario>@<dirección_del_servidor>

En la primera conexión, el servidor solicitará que confirmes la huella de su clave; así debe ser, introduce “yes” y pulsa Intro. Si la clave privada está protegida con una contraseña adicional, el sistema la solicitará. Después de esto, deberías acceder al sistema remoto; la invitación en la terminal cambiará. También puedes ejecutar siempre el comando hostname; siempre mostrará el nombre del host actual.

4. Desactivación de la autenticación mediante contraseña (recomendado). Una vez que hayas conseguido que el acceso mediante clave funcione, prohíbe el acceso mediante contraseña; así te desharás de los inconvenientes de la autenticación mediante contraseña y obtendrás todas las ventajas de la autenticación mediante clave. Edita el archivo de configuración SSH /etc/ssh/sshd_config en el servidor.

Importante: Asegúrate de que el acceso mediante claves funciona realmente antes de desactivar la contraseña. De lo contrario, solo podrás restaurar el acceso al servidor mediante la consola KVM o en el modo de rescate.

Cambia el parámetro PasswordAuthentication; su valor debe ser no. Asegúrate de que también está desactivada la opción ChallengeResponseAuthentication, que se encarga de la autenticación keyboard-interactive obsoleta. Para que los cambios surtan efecto, reinicia el servicio SSH:

sudo systemctl restart ssh

El servidor dejará de aceptar la contraseña después del reinicio. Ahora, el acceso solo es posible mediante claves.

Las claves SSH y su almacenamiento son un aspecto importante de la seguridad. Es conveniente tomar una serie de medidas sencillas para protegerse de acciones malintencionadas.

Recordemos que al crear un par de claves con la utilidad ssh-keygen, si no se cambia la ruta propuesta por defecto, se guardan en el directorio ~/.ssh:

• id_rsa o id_ed25519: clave privada (el nombre predeterminado depende del algoritmo utilizado).
• id_rsa.pub o id_ed25519.pub: clave pública.

Se recomienda proteger estos archivos del acceso no autorizado. El directorio .ssh debe tener los permisos 700, y la clave privada, 600 (solo el propietario puede leer y escribir). Si los permisos de acceso no están configurados correctamente, el servidor SSH puede denegar el acceso mediante clave por razones de seguridad.

También es una práctica habitual establecer una frase de contraseña (passphrase) en la clave privada al crearla. Entonces, se almacenará encriptada. Para utilizar la clave, será necesario introducir la frase de contraseña. Esta medida protege la clave privada incluso en caso de robo del archivo o de todo el dispositivo.

Para no tener que introducir la frase de contraseña cada vez, puedes utilizar la utilidad ssh-agent; solo será necesario introducir la passphrase una vez por sesión:

ssh-add ~/.ssh/my_key

Los pasos descritos anteriormente aumentan considerablemente la seguridad del acceso remoto. Ahora, en lugar de verificar el conocimiento de una contraseña que se puede adivinar, la autenticación se basa en la posesión de una clave privada: una prueba criptográfica prácticamente inmune a la adivinación o la falsificación.

Gestor de secretos

La implementación de claves SSH en lugar de contraseñas es un gran paso hacia la seguridad. Sin embargo, queda la cuestión de cómo almacenar de forma segura las propias claves y otros secretos, como contraseñas aleatorias para bases de datos, claves de API y datos confidenciales similares. No basta con generar una clave segura; es importante evitar su fuga o pérdida. Para resolver este problema, existe una herramienta especial: el gestor de secretos.

En combinación con las claves SSH, el gestor de secretos proporciona una solución de máxima seguridad: las claves se almacenan y transmiten de forma segura solo encriptadas bajo petición. Incluso si un atacante obtiene acceso limitado a tu infraestructura, le resultará extremadamente difícil extraer de ahí las claves privadas, ya que se almacenan en un repositorio encriptado separado.