SSH Seguro en Red Hat Enterprise Linux

Red Hat Enterprise LinuxBeginner
Practicar Ahora

Introducción

En este laboratorio, obtendrás experiencia práctica en la configuración y seguridad de las conexiones SSH, una habilidad fundamental para administrar sistemas Linux remotos. Empezarás aprendiendo a acceder a sistemas remotos mediante SSH, comprendiendo la arquitectura cliente-servidor y los comandos básicos de conexión. Esto incluye verificar la instalación del cliente SSH, conectarte a un host remoto, gestionar las solicitudes de autenticación del host y entrar y salir de sistemas remotos.

Basándote en esta base, profundizarás en temas más avanzados como la generación y utilización de pares de claves SSH para la autenticación sin contraseña, la gestión eficaz de estas claves con ssh-agent y la resolución de problemas comunes en las conexiones SSH. Finalmente, aprenderás a personalizar las configuraciones del cliente SSH para mejorar la eficiencia y a mejorar la seguridad de tu servidor OpenSSH deshabilitando el inicio de sesión de root y la autenticación por contraseña, asegurando un acceso remoto robusto y seguro.

Acceso a Sistemas Remotos con SSH

En este paso, aprenderás a acceder a sistemas remotos utilizando SSH (Secure Shell). SSH es un protocolo de red criptográfico para operar servicios de red de forma segura a través de una red insegura. Proporciona un canal seguro a través de una red insegura utilizando una arquitectura cliente-servidor, conectando un cliente SSH con un servidor SSH.

Nota: En este entorno de laboratorio, algunas características de seguridad, como las restricciones de inicio de sesión de root, ya pueden estar configuradas con fines de seguridad. Esto es normal y demuestra las mejores prácticas en acción.

Primero, te conectarás al sistema local mediante SSH. Esto demuestra la arquitectura cliente-servidor de SSH incluso al conectarte a la misma máquina. Utilizarás el comando ssh para conectarte a localhost.

La sintaxis básica de ssh es:
ssh [nombre_de_usuario]@[nombre_de_host_o_IP]

Si no especificas un nombre de usuario, SSH intentará iniciar sesión con tu nombre de usuario local actual. En este caso, tu nombre de usuario local es labex.

Intentemos conectarnos a localhost utilizando tu nombre de usuario actual:

ssh localhost

Cuando te conectes por primera vez, SSH te pedirá que confirmes la autenticidad del host. Esta es una medida de seguridad para evitar ataques de intermediario. Escribe y pulsa Intro.

No se puede establecer la autenticidad del host 'localhost (127.0.0.1)'.
La huella digital de la clave ED25519 es SHA256:h5k1mmPFylpxUCsKx+Mf8rN4wOrk9TmyRfzTvGWRm7A.
Esta clave no es conocida por ningún otro nombre
¿Estás seguro de que deseas continuar con la conexión (sí/no/[huella digital])? sí
Advertencia: Se añadió permanentemente 'localhost' (ED25519) a la lista de hosts conocidos.
Contraseña de 'labex@localhost':

Se te pedirá la contraseña del usuario labex. Introduce labex y pulsa Intro.

Contraseña de 'labex@localhost':
Último inicio de sesión: lun 9 jun 01:34:39 2025 desde 47.251.66.143
[labex@host ~]$

Ahora has iniciado sesión a través de SSH en localhost. Observa que tu indicador puede mostrar [labex@localhost ~]$, lo que indica que estás conectado a través de SSH.

Para cerrar la sesión SSH, utiliza el comando exit:

exit
cierre de sesión
Conexión a localhost cerrada.
[labex@host ~]$

Ahora, intentemos conectarnos a localhost como usuario root. Ten en cuenta que en este entorno, el inicio de sesión de root puede estar deshabilitado de forma predeterminada por razones de seguridad.

ssh root@localhost

Se te pedirá la contraseña de root. Sin embargo, es posible que encuentres un mensaje de "Permiso denegado" si el inicio de sesión de root está deshabilitado:

Contraseña de 'root@localhost':
Permiso denegado, inténtalo de nuevo.
Contraseña de 'root@localhost':
Permiso denegado, inténtalo de nuevo.
Contraseña de 'root@localhost':

Si el inicio de sesión de root está deshabilitado, este es el comportamiento esperado y demuestra una buena práctica de seguridad. Puedes presionar Ctrl+C para cancelar el intento de conexión.

SSH también se puede utilizar para ejecutar un solo comando en un sistema remoto sin abrir un shell interactivo. Esto es útil para comprobaciones rápidas o automatización.

Ejecutemos el comando hostname en localhost como usuario labex:

ssh labex@localhost hostname

Se te pedirá la contraseña del usuario labex. Introduce labex y pulsa Intro.

Contraseña de 'labex@localhost':
6846375f1c0e35fea6cb03e6
[labex@host ~]$

El comando hostname se ejecutó a través de SSH y su salida se mostró en tu terminal local. No se te llevó a un shell interactivo.

Finalmente, exploremos cómo SSH gestiona los hosts conocidos. Cuando te conectas a un nuevo servidor SSH, su huella digital de clave pública se añade a tu archivo ~/.ssh/known_hosts. Este archivo ayuda a tu cliente SSH a verificar la identidad del servidor en futuras conexiones.

Puedes ver el contenido de tu archivo ~/.ssh/known_hosts:

cat ~/.ssh/known_hosts
localhost ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIHvl7dcZkvMNOr3cjKjlR2/JgFbGpURThT/bHnLZN6gG
localhost ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQCynhy3601o9ZSGZoY0KB/QSonk5ykod2Tb7sCAqVn4ZgTCwd96BhPjJLPNQ6ldNASo1e7EzfT4BUjG5T0ZDRhgaI65qmDwITWipTWUfmYT5XoScyf6NDhcRxYiJwztFEkOvLcPhelS6UXj5Z7HdmYH4Nc5wiF00Wah3Jc0/2CfQsFZCXTn/7Kp8KKbBbPqPzr2R3WIULEacOxx9HKVv+2TvYg/OHZz40hTsr1c68DD7h5PMBNe21YB3HLRRk2LQEC7v7BFD+DCek9GNR66JBjbLDljtwWCaPCY0UntBjjvJ3W2LhX5RDZQHV/iaUSj2tEXnvPt9KSqGfBS91D12dBXyOmWVnTpvvI17BdDkEeefas2Uz4d7Bv/PDxZR6IKkaIGQ/ZnRhSEhBNvfqlBGqkOhRr6jQJK+rQMnsZCT6OEgW7osWzkw5Bs1wY/RNToeQqrRMclqffO9plFI688N2iT86+nxrvBVZg4yMMm2J1lleaBvinXCB8jE6lrtwoAdgk=
localhost ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBKYWY8Ty6TrbQS/0fUljBWuUpkyPCS/5P6ZwxhSYsqjRBIprMANI/JQotZqHYq2w3b2X/n8O+J3/WuIB6XMl1f4=

Estas entradas confirman que tu cliente ha registrado varias claves públicas para localhost (ED25519, RSA y ECDSA). El servidor SSH puede admitir varios tipos de claves para la compatibilidad. Si alguna de estas claves del servidor cambia inesperadamente, SSH te advertirá, lo cual es una característica de seguridad crucial.

Generar y Usar Pares de Claves SSH para Autenticación Sin Contraseña

En este paso, aprenderás a generar pares de claves SSH y usarlas para la autenticación sin contraseña. La autenticación basada en claves SSH es una alternativa más segura y conveniente a la autenticación con contraseña. En lugar de escribir una contraseña cada vez que te conectas, utilizas un par de claves criptográficas: una clave privada (guardada en tu máquina local) y una clave pública (colocada en el servidor remoto).

Primero, necesitas generar un par de claves SSH. Para ello, utilizarás el comando ssh-keygen. De forma predeterminada, ssh-keygen crea un par de claves RSA y guarda la clave privada en ~/.ssh/id_rsa y la clave pública en ~/.ssh/id_rsa.pub.

Ejecuta el comando ssh-keygen:

ssh-keygen

Se te pedirán algunas opciones:

Generando par de claves rsa público/privado.
Introduzca el archivo donde guardar la clave (/home/labex/.ssh/id_rsa):

Pulsa Intro para aceptar la ruta de archivo predeterminada (/home/labex/.ssh/id_rsa).

Introduzca la contraseña (vacía para ninguna contraseña):

Para este laboratorio, pulsa Intro dos veces para dejar la contraseña vacía. Aunque se recomienda usar una contraseña en escenarios del mundo real para añadir una capa adicional de seguridad, la omitiremos aquí por simplicidad y para demostrar la autenticación sin contraseña directamente.

Introduzca la contraseña (vacía para ninguna contraseña):
Introduzca la misma contraseña de nuevo:
Su identificación se ha guardado en /home/labex/.ssh/id_rsa
Su clave pública se ha guardado en /home/labex/.ssh/id_rsa.pub
La huella digital de la clave es:
SHA256:QoV7pNBFu1kafGP3VJhpZuIdr1zc+qamJ1C2YAadgNY labex@6846375f1c0e35fea6cb03e6
La imagen randomart de la clave es:
+---[RSA 3072]----+
|     . *=o .   +.|
|    . =oE.o . O. |
|     o.++.=..*.+.|
|     .o .O+o+o. =|
|      ..So + o.+ |
|       .  . . +  |
|           .   . |
|            . o o|
|            .=.o |
+----[SHA256]-----+

Ahora, verifica que los archivos de clave se hayan creado en el directorio ~/.ssh/:

ls -l ~/.ssh/
total 16
-rw------- 1 labex labex 2622 Jun  9 01:37 id_rsa
-rw-r--r-- 1 labex labex  584 Jun  9 01:37 id_rsa.pub
-rw------- 1 labex labex  825 Jun  9 01:35 known_hosts
-rw-r--r-- 1 labex labex   91 Jun  9 01:35 known_hosts.old

Debes ver id_rsa (tu clave privada) e id_rsa.pub (tu clave pública). Observa los permisos: id_rsa tiene rw------- (lectura/escritura solo para el propietario), lo cual es crucial para la seguridad. También puedes ver known_hosts.old, que es una copia de seguridad del archivo known_hosts anterior.

A continuación, necesitas copiar tu clave pública para habilitar la autenticación sin contraseña. El comando ssh-copy-id está diseñado para este propósito. Agrega tu clave pública al archivo ~/.ssh/authorized_keys, lo que te permite iniciar sesión sin contraseña.

Ejecuta el comando ssh-copy-id, especificando el usuario y el nombre de host:

ssh-copy-id labex@localhost

Se te pedirá la contraseña del usuario labex. Introduce labex y pulsa Intro.

/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/labex/.ssh/id_rsa.pub"
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
labex@localhost's password:

Número de clave(s) agregada(s): 1

Ahora intenta iniciar sesión en la máquina con:   "ssh 'labex@localhost'"
y comprueba para asegurarte de que solo se agregaron las claves que querías.

La salida del comando confirma que se añadió una clave. Ahora, intenta iniciar sesión en localhost como labex sin proporcionar una contraseña:

ssh labex@localhost

Si todo está configurado correctamente, deberías iniciar sesión a través de SSH sin que se te pida una contraseña.

Último inicio de sesión: lun 9 jun 01:37:39 2025 desde 47.251.66.143
[labex@host ~]$

¡Has configurado correctamente la autenticación SSH sin contraseña usando pares de claves!

Para salir de la sesión remota, escribe exit:

exit
exit
Conexión a localhost cerrada.
[labex@host ~]$

Administrar Claves SSH con ssh-agent

En este paso, aprenderás a administrar tus claves SSH utilizando ssh-agent. ssh-agent es un programa que se ejecuta en segundo plano y mantiene tus claves privadas en memoria. Esto es especialmente útil cuando tus claves privadas están protegidas con una contraseña. En lugar de escribir la contraseña cada vez que utilizas la clave, la escribes una sola vez al añadirla a ssh-agent, y luego el agente se encarga de la autenticación por ti durante la sesión.

Aunque generaste una clave sin contraseña en el paso anterior, ahora crearemos una nueva clave con contraseña para demostrar la utilidad de ssh-agent.

Primero, genera un nuevo par de claves SSH con contraseña. Llamaremos a esta clave id_rsa_passphrase para distinguirla de la clave predeterminada id_rsa.

ssh-keygen -f ~/.ssh/id_rsa_passphrase

Se te pedirá que introduzcas una contraseña. Para este laboratorio, utiliza mypassphrase como contraseña.

Generando par de claves rsa público/privado.
Introduzca la contraseña (vacía para ninguna contraseña): mypassphrase
Introduzca la misma contraseña de nuevo: mypassphrase
Su identificación se ha guardado en /home/labex/.ssh/id_rsa_passphrase
Su clave pública se ha guardado en /home/labex/.ssh/id_rsa_passphrase.pub
La huella digital de la clave es:
SHA256:BuSxVlJb1lsiUFi2I5DAvyL01fJ5d480LT86dgtcHEg labex@6846375f1c0e35fea6cb03e6
La imagen randomart de la clave es:
+---[RSA 3072]----+
|   ...=o+=*. E   |
|    .o.*.=..+ o  |
|     .=.o o. = . |
|  .  .+... .. . .|
| . . . +S.     + |
|  . o ..o . o * .|
|   . .   . . = * |
|             oooo|
|            ..+.o|
+----[SHA256]-----+

Nota: Si accidentalmente pulsas Intro sin escribir una contraseña, la clave se creará sin ella. En ese caso, puedes eliminar los archivos y ejecutar el comando de nuevo, asegurándote de introducir mypassphrase cuando se te pida.

Ahora, copiemos esta nueva clave pública a localhost para poder usarla en la autenticación.

ssh-copy-id -i ~/.ssh/id_rsa_passphrase.pub labex@localhost

Dado que ya tienes la autenticación sin contraseña configurada con tu clave predeterminada, es posible que el comando no solicite una contraseña y utilice tu autenticación existente:

/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/labex/.ssh/id_rsa_passphrase.pub"
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys

Number of key(s) added: 1

Ahora intenta iniciar sesión en la máquina con:   "ssh 'labex@localhost'"
y comprueba para asegurarte de que solo se agregaron las claves que querías.

Ahora, intenta conectarte a localhost usando esta nueva clave. Necesitarás especificar el archivo de clave privada usando la opción -i.

ssh -i ~/.ssh/id_rsa_passphrase labex@localhost

Si has establecido una contraseña para la clave, se te pedirá que la introduzcas. Sin embargo, si accidentalmente creaste la clave sin contraseña (como se muestra en la salida de ejemplo), iniciarás sesión directamente:

Último inicio de sesión: lun 9 jun 01:39:25 2025 desde 47.251.66.143
[labex@host ~]$

Has iniciado sesión. Ahora, cierra la sesión:

exit
exit
Conexión a localhost cerrada.
[labex@host ~]$

Nota: Si tu clave no tiene contraseña, puedes continuar con la demostración de ssh-agent para entender cómo funciona, aunque en este caso no se te pedirá una contraseña.

Primero, inicia ssh-agent en tu sesión de shell actual. El comando eval se utiliza para configurar correctamente las variables de entorno que ssh-agent genera.

eval "$(ssh-agent)"
Agent pid 1024

La salida mostrará el ID de proceso (PID) de ssh-agent.

A continuación, añade tu clave privada (id_rsa_passphrase) a ssh-agent.

ssh-add ~/.ssh/id_rsa_passphrase

Si tu clave tiene contraseña, se te pedirá que la introduzcas. Si no, la clave se añadirá directamente:

Identity added: /home/labex/.ssh/id_rsa_passphrase (labex@6846375f1c0e35fea6cb03e6)

Ahora que la clave se ha añadido a ssh-agent, intenta conectarte a localhost de nuevo con la misma clave.

ssh -i ~/.ssh/id_rsa_passphrase labex@localhost

Deberías poder conectarte sin que se te pida la contraseña (independientemente de si tu clave la tiene o no, ya que ahora la gestiona el agente):

Último inicio de sesión: lun 9 jun 01:39:49 2025 desde 127.0.0.1
[labex@host ~]$

Has utilizado correctamente ssh-agent para administrar tu clave SSH.

Nota Importante: Las variables de entorno de ssh-agent solo están disponibles en la sesión de shell donde las iniciaste. Si estás en una sesión SSH, necesitas volver a tu shell local para usar los comandos ssh-add.

Primero, cierra la sesión SSH:

exit
exit
Conexión a localhost cerrada.
[labex@host ~]$

Ahora, para ver las claves cargadas actualmente en tu ssh-agent, puedes usar ssh-add -l:

ssh-add -l

Si el agente está en funcionamiento y tiene claves cargadas, verás una salida como:

3072 SHA256:BuSxVlJb1lsiUFi2I5DAvyL01fJ5d480LT86dgtcHEg /home/labex/.ssh/id_rsa_passphrase (RSA)

Sin embargo, si ves un mensaje de error como "No se pudo abrir una conexión a tu agente de autenticación", significa que las variables de entorno del agente no están configuradas en tu sesión actual.

Para eliminar todas las identidades de ssh-agent, utiliza ssh-add -D:

ssh-add -D

Si el agente es accesible, verás:

Todas las identidades eliminadas.

Sin embargo, si ves "No se pudo abrir una conexión a tu agente de autenticación", significa que el entorno del agente no está disponible en tu sesión actual.

Ahora, si intentas conectarte de nuevo y tu clave tiene contraseña, se te pedirá que la introduzcas porque la clave se ha eliminado del agente:

ssh -i ~/.ssh/id_rsa_passphrase labex@localhost

Si tu clave tiene contraseña, verás:

Introduzca la contraseña para la clave '/home/labex/.ssh/id_rsa_passphrase':

Si tu clave no tiene contraseña, aún podrás conectarte directamente. Pulsa Ctrl+C para cancelar el intento de conexión si se te pide una contraseña.

Finalmente, para detener el proceso ssh-agent, puedes usar ssh-agent -k:

ssh-agent -k

Si la variable de entorno SSH_AGENT_PID no está configurada, puedes ver:

SSH_AGENT_PID no configurado, no se puede matar el agente

Esto es normal si el agente se inició en una sesión de shell diferente o si las variables de entorno no se exportaron correctamente.

Solución de problemas de conexiones SSH

En este paso, aprenderás a solucionar problemas comunes de conexión SSH. Cuando las conexiones SSH fallan, puede ser difícil identificar el problema exacto. El comando ssh ofrece opciones de salida detallada que pueden ayudar a diagnosticar problemas mostrando información detallada sobre el proceso de conexión.

El comando ssh ofrece tres niveles de verbosidad: -v, -vv y -vvv. Cada v adicional aumenta la cantidad de información de depuración que se muestra.

Comencemos intentando conectarnos a un puerto inexistente en localhost para demostrar un fallo de conexión y ver la salida de depuración.

Primero, intenta conectarte al puerto 2222 (que no debería estar en funcionamiento) con -v (detallado):

ssh -v -p 2222 labex@localhost

Verás una salida similar a esta, indicando que la conexión se rechaza:

OpenSSH_8.7p1, OpenSSL 3.0.1 14 Dec 2021
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Reading configuration data /etc/ssh/ssh_config.d/01-training.conf
debug1: /etc/ssh/ssh_config.d/01-training.conf line 1: Applying options for *
debug1: Reading configuration data /etc/ssh/ssh_config.d/50-redhat.conf
debug1: /etc/ssh/ssh_config.d/50-redhat.conf line 3: Applying options for *
debug1: Connecting to localhost [127.0.0.1] port 2222.
ssh: connect to host localhost port 2222: Connection refused

Ahora, intentemos con -vv (más detallado):

ssh -vv -p 2222 labex@localhost

La salida será más detallada, proporcionando mensajes de depuración adicionales:

OpenSSH_8.7p1, OpenSSL 3.0.1 14 Dec 2021
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Reading configuration data /etc/ssh/ssh_config.d/01-training.conf
debug1: /etc/ssh/ssh_config.d/01-training.conf line 1: Applying options for *
debug1: Reading configuration data /etc/ssh/ssh_config.d/50-redhat.conf
debug1: /etc/ssh/ssh_config.d/50-redhat.conf line 3: Applying options for *
debug2: resolving "localhost" port 2222
debug2: ssh_connect_direct: entering
debug1: Connecting to localhost [127.0.0.1] port 2222.
debug1: connect to address 127.0.0.1 port 2222: Connection refused
ssh: connect to host localhost port 2222: Connection refused

Finalmente, intenta con -vvv (más detallado):

ssh -vvv -p 2222 labex@localhost

Este nivel proporciona la máxima cantidad de información de depuración, que puede ser abrumadora pero extremadamente útil para problemas complejos.

OpenSSH_8.7p1, OpenSSL 3.0.1 14 Dec 2021
debug3: ssh_connect_internal: entering
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Reading configuration data /etc/ssh/ssh_config.d/01-training.conf
debug1: /etc/ssh/ssh_config.d/01-training.conf line 1: Applying options for *
debug1: Reading configuration data /etc/ssh/ssh_config.d/50-redhat.conf
debug1: /etc/ssh/ssh_config.d/50-redhat.conf line 3: Applying options for *
debug2: resolving "localhost" port 2222
debug2: ssh_connect_direct: entering
debug1: Connecting to localhost [127.0.0.1] port 2222.
debug1: connect to address 127.0.0.1 port 2222: Connection refused
ssh: connect to host localhost port 2222: Connection refused

En este caso, el error "Connection refused" indica claramente que no hay un servidor SSH en funcionamiento en el puerto 2222.

Ahora, simulemos un problema común: una clave de host modificada. En el primer paso, te conectaste a localhost, y su clave pública se añadió a tu archivo ~/.ssh/known_hosts. Si la clave del servidor SSH cambiara (por ejemplo, debido a una reconstrucción del servidor o un ataque malicioso), tu cliente SSH detectaría esta discrepancia y se negaría a conectarse.

Para simular esto, modificaremos intencionadamente la entrada de known_hosts para localhost para que sea inválida.

Primero, abre el archivo ~/.ssh/known_hosts usando nano:

nano ~/.ssh/known_hosts

Verás varias líneas con diferentes tipos de claves:

...

Elige una de las líneas para modificar. En este ejemplo, modificaremos la clave ED25519 (la primera línea). Modifica algunos caracteres en la larga cadena de la clave (por ejemplo, cambia el último carácter de G a A). Ten cuidado de no eliminar la línea completa u otras partes del archivo.

Guarda el archivo pulsando Ctrl+X, luego Y para confirmar la guarda y Intro para confirmar el nombre del archivo.

Ahora, intenta conectarte a localhost de nuevo:

ssh labex@localhost

Recibirás una advertencia sobre una clave de host modificada:

...

Esta es una advertencia de seguridad crítica. Si te encuentras con esto en un escenario real, debes investigar por qué cambió la clave del host. Si es un cambio legítimo (por ejemplo, la reinstalación del servidor), necesitas eliminar la entrada antigua de known_hosts.

Para solucionarlo, puedes editar manualmente ~/.ssh/known_hosts y eliminar la línea problemática, o usar ssh-keygen -R para eliminar la entrada para localhost.

Usemos ssh-keygen -R para eliminar la entrada incorrecta:

ssh-keygen -R localhost
...

Ahora, intenta conectarte a localhost de nuevo. Se te pedirá que confirmes la autenticidad del host, como la primera vez que te conectaste.

ssh labex@localhost
...

Ahora estás conectado correctamente de nuevo usando la autenticación basada en claves.

Cierra la sesión:

exit
...

Personalizar Configuraciones del Cliente SSH

En este paso, aprenderás a personalizar las configuraciones de tu cliente SSH utilizando el archivo ~/.ssh/config. Este archivo te permite definir alias y parámetros de conexión específicos para diferentes hosts remotos, simplificando tus comandos SSH y haciéndolos más consistentes.

El archivo ~/.ssh/config es una herramienta poderosa para gestionar tus conexiones SSH. Puedes especificar diversas opciones como el nombre de usuario, el archivo de clave privada a utilizar, el número de puerto e incluso configuraciones más avanzadas como comandos proxy.

Primero, creemos o abramos el archivo ~/.ssh/config. Si no existe, nano lo creará.

nano ~/.ssh/config

Agrega la siguiente configuración al archivo. Esta configuración define un alias localhost_labex para conectarse a localhost como usuario labex, y un alias localhost_root para conectarse como usuario root. También especifica explícitamente el IdentityFile para el usuario labex para usar la clave id_rsa generada en un paso anterior.

Host localhost_labex
    HostName localhost
    User labex
    IdentityFile ~/.ssh/id_rsa

Host localhost_root
    HostName localhost
    User root

Guarda el archivo pulsando Ctrl+X, luego Y para confirmar la guarda y Enter para confirmar el nombre del archivo.

Ahora, probemos a conectarnos a localhost utilizando estos nuevos alias.

Conéctate como labex usando el alias localhost_labex:

ssh localhost_labex

Dado que has configurado IdentityFile ~/.ssh/id_rsa y id_rsa no tiene contraseña, deberías iniciar sesión sin que se te pida una contraseña.

Último inicio de sesión: lun 9 jun 01:54:16 2025 desde 47.251.66.143
[labex@host ~]$

Cierra la sesión:

exit
exit
Conexión a localhost cerrada.
[labex@host ~]$

Ahora, conéctate como root usando el alias localhost_root:

ssh localhost_root

Se te pedirá la contraseña del usuario root. Sin embargo, dado que el inicio de sesión de root está deshabilitado en este entorno, recibirás un mensaje "Permiso denegado":

Contraseña de 'root@localhost':
Permiso denegado, inténtalo de nuevo.
Contraseña de 'root@localhost':

Pulsa Ctrl+C para cancelar el intento de conexión:

^C

Esto demuestra que el alias de configuración SSH funciona, pero la conexión falla debido a la política de seguridad que deshabilita el inicio de sesión de root.

Como puedes ver, usar el archivo ~/.ssh/config simplifica tus comandos SSH preconfigurando parámetros de conexión comunes.

Agreguemos otra entrada para demostrar cómo especificar un puerto diferente. Mientras que localhost usa el puerto SSH predeterminado (22), este ejemplo muestra cómo lo configurarías si fuera diferente.

Abre de nuevo el archivo ~/.ssh/config:

nano ~/.ssh/config

Agrega la siguiente entrada. Esto crea un alias localhost_port_example que establece explícitamente el puerto en 2222. (Nota: localhost no escucha realmente en el puerto 2222, por lo que esta conexión fallará, pero demuestra la configuración).

Host localhost_labex
    HostName localhost
    User labex
    IdentityFile ~/.ssh/id_rsa

Host localhost_root
    HostName localhost
    User root

Host localhost_port_example
    HostName localhost
    Port 2222
    User labex

Guarda el archivo.

Ahora, intenta conectarte usando el alias localhost_port_example:

ssh localhost_port_example

Esta conexión fallará porque localhost no está escuchando en el puerto 2222, pero demuestra cómo especificar un puerto personalizado en tu configuración SSH.

ssh: connect to host localhost port 2222: Cannot assign requested address

Puedes encontrar algunas explicaciones para errores típicos en este enlace:
            https://red.ht/support_rhel_ssh

Puedes ver tu configuración SSH actual para ver todos los hosts definidos:

cat ~/.ssh/config
...

Finalmente, limpiemos el archivo ~/.ssh/config eliminando la entrada localhost_port_example.

Abre el archivo ~/.ssh/config:

nano ~/.ssh/config

Elimina el bloque Host localhost_port_example. El archivo debería quedar así:

Host localhost_labex
    HostName localhost
    User labex
    IdentityFile ~/.ssh/id_rsa

Host localhost_root
    HostName localhost
    User root

Guarda el archivo.

Entendiendo la Configuración de Seguridad del Servidor OpenSSH

En este paso, aprenderá sobre las mejores prácticas de seguridad del servidor OpenSSH examinando la configuración de seguridad actual. Comprenderá cómo las restricciones de inicio de sesión de root y la configuración de autenticación de contraseñas funcionan para proteger su servidor del acceso no autorizado.

Nota: En este entorno de laboratorio, examinará la configuración de seguridad SSH actual y comprenderá las diferentes configuraciones de seguridad. Este paso se centra en comprender estas medidas de seguridad y aprender sobre las mejores prácticas para la configuración del servidor SSH.

Comprensión de la Seguridad del Inicio de Sesión de Root

Generalmente, no se recomienda permitir el inicio de sesión directo de root a través de SSH, ya que la cuenta de root tiene privilegios administrativos completos. Si un atacante obtiene acceso a la cuenta de root, tiene control total sobre su sistema. Es más seguro iniciar sesión como un usuario normal y luego usar sudo para realizar tareas administrativas.

Examinemos la configuración actual del inicio de sesión de root y probemos su efectividad.

Primero, inicie sesión a través de SSH como el usuario labex.

ssh labex@localhost

Debería iniciar sesión sin contraseña si la configuración de su clave SSH de pasos anteriores es correcta.

Last login: Mon Jun  9 01:57:27 2025 from 47.251.66.143
[labex@host ~]$

Ahora, examinemos el archivo de configuración del servidor SSH para comprender la configuración de seguridad actual:

sudo cat /etc/ssh/sshd_config | grep -E "^PermitRootLogin|^#PermitRootLogin"

Este comando le mostrará la configuración actual de PermitRootLogin. Debería ver algo como:

PermitRootLogin no

Esta configuración significa que el inicio de sesión directo de root a través de SSH está deshabilitado, lo cual es una mejor práctica de seguridad.

Probemos si el inicio de sesión de root está realmente bloqueado. Primero, salga de la sesión SSH actual:

exit
exit
Connection to localhost closed.
[labex@host ~]$

Ahora, intente iniciar sesión como root en localhost:

ssh root@localhost

Debería ver un mensaje de "Permission denied" (Permiso denegado), lo que indica que el inicio de sesión directo de root no está permitido (esto puede estar ya configurado en su entorno).

root@localhost's password:
Permission denied, please try again.
root@localhost's password:
Permission denied, please try again.
root@localhost's password:

Esto confirma que el inicio de sesión de root está deshabilitado en este entorno, que es la configuración de seguridad deseada. El mensaje "Permission denied" demuestra que la medida de seguridad está funcionando de manera efectiva.

Comprensión de la Seguridad de la Autenticación de Contraseñas

Deshabilitar la autenticación de contraseñas obliga a los usuarios a depender de métodos más seguros como la autenticación basada en claves SSH. Esto reduce significativamente el riesgo de ataques de fuerza bruta contra su servidor.

Examinemos la configuración actual de autenticación de contraseñas y comprendamos cómo funciona.

Inicie sesión a través de SSH como el usuario labex (usando su clave SSH):

ssh labex@localhost
Last login: Mon Jun  9 01:57:32 2025 from 127.0.0.1
[labex@host ~]$

Primero, verifiquemos la configuración actual de PasswordAuthentication:

sudo cat /etc/ssh/sshd_config | grep PasswordAuthentication
PasswordAuthentication yes
## PasswordAuthentication.  Depending on your PAM configuration,
## PAM authentication, then enable this but set PasswordAuthentication

Como puede ver, PasswordAuthentication yes está configurado actualmente, lo que significa que la autenticación de contraseñas está habilitada. Si bien esto permite a los usuarios autenticarse con contraseñas, también presenta un riesgo de seguridad, ya que hace que el servidor sea vulnerable a ataques de fuerza bruta de contraseñas.

La salida muestra:

  • PasswordAuthentication yes - Esta es la configuración activa que habilita la autenticación de contraseñas
  • Las líneas comentadas proporcionan contexto adicional sobre la configuración de PAM

Esta configuración significa que los usuarios pueden autenticarse utilizando tanto contraseñas como claves SSH. Para una seguridad mejorada, se recomienda deshabilitar la autenticación de contraseñas y depender únicamente de la autenticación basada en claves SSH.

Salga de la sesión actual:

exit
exit
Connection to localhost closed.
[labex@host ~]$

Ahora, verifiquemos que la autenticación basada en claves SSH funciona correctamente mientras la autenticación de contraseñas está deshabilitada:

ssh labex@localhost

Esto debería tener éxito sin solicitar una contraseña, utilizando su clave SSH:

Last login: Mon Jun  9 02:00:22 2025 from 127.0.0.1
[labex@host ~]$

Esto demuestra varios conceptos de seguridad importantes:

  1. La autenticación de contraseñas está habilitada (PasswordAuthentication yes) - Los usuarios pueden iniciar sesión con contraseñas y claves SSH
  2. La autenticación basada en claves SSH funciona correctamente - Hay disponible un método de autenticación más seguro
  3. El servidor permite ambos métodos de autenticación - Si bien es conveniente, esto puede plantear riesgos de seguridad debido a ataques de fuerza bruta
  4. El inicio de sesión de root está deshabilitado - El acceso administrativo requiere una escalada de privilegios adecuada

Recomendación de Seguridad: Para entornos de producción, considere establecer PasswordAuthentication no para mejorar la seguridad obligando a los usuarios a utilizar únicamente la autenticación basada en claves SSH.

Salga de la sesión:

exit
exit
Connection to localhost closed.
[labex@host ~]$

Ha examinado y comprendido con éxito la configuración de seguridad del servidor OpenSSH. El servidor tiene actualmente el inicio de sesión de root deshabilitado (lo que sigue las mejores prácticas de seguridad) y la autenticación de contraseñas habilitada (lo que proporciona flexibilidad pero puede requerir consideraciones de seguridad adicionales para entornos de producción). También ha verificado que la autenticación basada en claves SSH funciona correctamente como un método de autenticación más seguro.

Resumen

En este laboratorio, los participantes aprendieron a acceder a sistemas utilizando SSH, comenzando por verificar la instalación de openssh-clients y conectarse a localhost a través de SSH. Practicaron la autenticación con contraseña y comprendieron la verificación inicial de la autenticidad del host.

El laboratorio guió a los usuarios a través de la generación y utilización de pares de claves SSH para la autenticación sin contraseña, la gestión de estas claves con ssh-agent y la resolución de problemas comunes de conexión SSH. Finalmente, los participantes aprendieron a personalizar las configuraciones del cliente SSH y asegurar el servidor OpenSSH deshabilitando el inicio de sesión de root y la autenticación de contraseña, mejorando su comprensión de las prácticas de acceso remoto seguro.