Introducción
En este laboratorio, obtendrás experiencia práctica en la configuración y protección de conexiones SSH, una habilidad fundamental para gestionar sistemas Linux remotos. Comenzarás aprendiendo cómo 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, conectarse a un host remoto, gestionar las solicitudes de autenticidad del host e iniciar y cerrar sesión en sistemas remotos.
Sobre 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 efectiva de estas claves con ssh-agent y la resolución de problemas comunes de conexión SSH. Finalmente, aprenderás a personalizar las configuraciones del cliente SSH para mejorar la eficiencia y fortalecer la seguridad de tu servidor OpenSSH deshabilitando el inicio de sesión de root y la autenticación por contraseña, garantizando un acceso remoto robusto y seguro.
Acceder a sistemas remotos con SSH
En este paso, aprenderás cómo acceder a sistemas remotos utilizando SSH (Secure Shell). SSH es un protocolo de red criptográfico para operar servicios de red de forma segura sobre una red no segura. Proporciona un canal seguro mediante una arquitectura cliente-servidor, conectando un cliente SSH con un servidor SSH.
Nota: En este entorno de laboratorio, algunas funciones de seguridad, como las restricciones de inicio de sesión de root, pueden estar ya configuradas por motivos de seguridad. Esto es normal y demuestra las mejores prácticas en acción.
Antes de conectarte a sistemas remotos, prepara tu entorno de laboratorio instalando los paquetes del cliente y servidor OpenSSH e iniciando el servicio SSH. SSH utiliza una arquitectura cliente-servidor: el cliente (ssh) inicia las conexiones y el servidor (sshd) las acepta. También instalarás nano, que utilizarás más adelante para editar los archivos de configuración de SSH.
Ejecuta el siguiente comando para instalar los paquetes necesarios. El indicador -y confirma automáticamente las solicitudes de instalación de paquetes:
sudo dnf install -y openssh-clients openssh-server nano
Inicia el servicio SSH y configúralo para que se inicie automáticamente al arrancar:
sudo systemctl start sshd
sudo systemctl enable sshd
Verifica que el servicio SSH esté en ejecución:
sudo systemctl status sshd
Deberías ver Active: active (running) en la salida. Presiona q para salir de la vista de estado.
Primero, te conectarás al sistema local usando SSH. Esto demuestra la arquitectura cliente-servidor de SSH incluso al conectarse a la misma máquina. Utilizarás el comando ssh para conectarte a localhost.
La sintaxis básica para 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 usando 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 (man-in-the-middle). Escribe yes y presiona Enter.
The authenticity of host 'localhost (127.0.0.1)' can't be established.
ED25519 key fingerprint is SHA256:h5k1mmPFylpxUCsKx+Mf8rN4wOrk9TmyRfzTvGWRm7A.
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'localhost' (ED25519) to the list of known hosts.
labex@localhost's password:
Se te solicitará la contraseña del usuario labex. Ingresa labex y presiona Enter.
labex@localhost's password:
Last login: Mon Jun 9 01:34:39 2025 from 47.251.66.143
[labex@host ~]$
Ahora has iniciado sesión vía SSH en localhost. Observa que tu prompt puede mostrar [labex@localhost ~]$, lo que indica que estás conectado vía SSH.
Para cerrar la sesión SSH, utiliza el comando exit:
exit
logout
Connection to localhost closed.
[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 por defecto por razones de seguridad.
ssh root@localhost
Se te solicitará la contraseña de root. Sin embargo, es posible que encuentres un mensaje de "Permission denied" si el inicio de sesión de root está deshabilitado:
root@localhost's password:
Permission denied, please try again.
root@localhost's password:
Permission denied, please try again.
root@localhost's password:
Si el inicio de sesión de root está deshabilitado, este es el comportamiento esperado y demuestra una mejor 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 una shell interactiva. 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 solicitará la contraseña del usuario labex. Ingresa labex y presiona Enter.
labex@localhost's password:
6846375f1c0e35fea6cb03e6
[labex@host ~]$
El comando hostname se ejecutó vía SSH y su salida se mostró en tu terminal local. No se te redirigió a una shell interactiva.
Finalmente, exploremos cómo SSH gestiona los hosts conocidos. Cuando te conectas a un nuevo servidor SSH, la huella digital de su 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 múltiples claves públicas para localhost (ED25519, RSA y ECDSA). El servidor SSH puede admitir múltiples tipos de claves por compatibilidad. Si alguna de estas claves del servidor cambia inesperadamente, SSH te advertirá, lo cual es una característica de seguridad crucial.
Generar y utilizar pares de claves SSH para autenticación sin contraseña
En este paso, aprenderás cómo generar pares de claves SSH y utilizarlos 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 por contraseña. En lugar de escribir una contraseña cada vez que te conectas, utilizas un par de claves criptográficas: una clave privada (que se mantiene secreta en tu máquina local) y una clave pública (que se coloca en el servidor remoto).
Primero, necesitas generar un par de claves SSH. Utilizarás el comando ssh-keygen para este propósito. Por defecto, 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 solicitarán algunas opciones:
Generating public/private rsa key pair.
Enter file in which to save the key (/home/labex/.ssh/id_rsa):
Presiona Enter para aceptar la ruta de archivo predeterminada (/home/labex/.ssh/id_rsa).
Enter passphrase (empty for no passphrase):
Para este laboratorio, presiona Enter dos veces para dejar la frase de contraseña vacía. Aunque se recomienda usar una frase de contraseña en escenarios del mundo real para añadir una capa extra de seguridad, aquí la omitiremos por simplicidad y para demostrar directamente la autenticación sin contraseña.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/labex/.ssh/id_rsa
Your public key has been saved in /home/labex/.ssh/id_rsa.pub
The key fingerprint is:
SHA256:QoV7pNBFu1kafGP3VJhpZuIdr1zc+qamJ1C2YAadgNY labex@6846375f1c0e35fea6cb03e6
The key's randomart image is:
+---[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
Deberías 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. Añade tu clave pública al archivo ~/.ssh/authorized_keys, permitiéndote 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 solicitará la contraseña del usuario labex. Ingresa labex y presiona Enter.
/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:
Number of key(s) added: 1
Now try logging into the machine, with: "ssh 'labex@localhost'"
and check to make sure that only the key(s) you wanted were added.
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 vía SSH sin que se te solicite una contraseña.
Last login: Mon Jun 9 01:37:39 2025 from 47.251.66.143
[labex@host ~]$
¡Has configurado con éxito la autenticación SSH sin contraseña utilizando pares de claves!
Para salir de la sesión remota, escribe exit:
exit
exit
Connection to localhost closed.
[labex@host ~]$
Gestionar claves SSH con ssh-agent
En este paso, aprenderás cómo gestionar tus claves SSH utilizando ssh-agent. El ssh-agent es un programa que se ejecuta en segundo plano y mantiene tus claves privadas en memoria. Esto es particularmente útil cuando tus claves privadas están protegidas por una frase de contraseña. En lugar de escribir la frase de contraseña cada vez que utilizas la clave, la escribes una vez cuando añades la clave al ssh-agent, y luego el agente maneja la autenticación por ti durante la duración de tu sesión.
Aunque generaste una clave sin frase de contraseña en el paso anterior, ahora crearemos una nueva clave con una frase de contraseña para demostrar la utilidad de ssh-agent.
Primero, genera un nuevo par de claves SSH con una frase de contraseña. Llamaremos a esta clave id_rsa_passphrase para distinguirla de la clave id_rsa predeterminada.
ssh-keygen -f ~/.ssh/id_rsa_passphrase
Se te solicitará ingresar una frase de contraseña. Para este laboratorio, usa mypassphrase como frase de contraseña.
Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase): mypassphrase
Enter same passphrase again: mypassphrase
Your identification has been saved in /home/labex/.ssh/id_rsa_passphrase
Your public key has been saved in /home/labex/.ssh/id_rsa_passphrase.pub
The key fingerprint is:
SHA256:BuSxVlJb1lsiUFi2I5DAvyL01fJ5d480LT86dgtcHEg labex@6846375f1c0e35fea6cb03e6
The key's randomart image is:
+---[RSA 3072]----+
| ...=o+=*. E |
| .o.*.=..+ o |
| .=.o o. = . |
| . .+... .. . .|
| . . . +S. + |
| . o ..o . o * .|
| . . . . = * |
| oooo|
| ..+.o|
+----[SHA256]-----+
Nota: Si presionas Enter accidentalmente sin escribir una frase de contraseña, la clave se creará sin ella. En ese caso, puedes eliminar los archivos y ejecutar el comando de nuevo, asegurándote de ingresar mypassphrase cuando se te solicite.
Ahora, copiemos esta nueva clave pública a localhost para que puedas usarla para la autenticación.
ssh-copy-id -i ~/.ssh/id_rsa_passphrase.pub labex@localhost
Dado que ya tienes configurada la autenticación sin contraseña 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
Now try logging into the machine, with: "ssh 'labex@localhost'"
and check to make sure that only the key(s) you wanted were added.
Ahora, intenta conectarte a localhost usando esta nueva clave. Deberás especificar el archivo de clave privada usando la opción -i.
ssh -i ~/.ssh/id_rsa_passphrase labex@localhost
Si estableciste una frase de contraseña para la clave, se te solicitará. Sin embargo, si creaste accidentalmente la clave sin una frase de contraseña (como se muestra en la salida de ejemplo), iniciarás sesión directamente:
Last login: Mon Jun 9 01:39:25 2025 from 47.251.66.143
[labex@host ~]$
Has iniciado sesión. Ahora, cierra la sesión:
exit
exit
Connection to localhost closed.
[labex@host ~]$
Nota: Si tu clave no tiene una frase de contraseña, aún puedes continuar con la demostración de ssh-agent para entender cómo funciona, aunque no solicitará una frase de contraseña en este caso.
Primero, inicia el ssh-agent en tu sesión de shell actual. El comando eval se utiliza para establecer correctamente las variables de entorno que genera ssh-agent.
eval "$(ssh-agent)"
Agent pid 1024
La salida mostrará el ID de proceso (PID) del ssh-agent.
A continuación, añade tu clave privada (id_rsa_passphrase) al ssh-agent.
ssh-add ~/.ssh/id_rsa_passphrase
Si tu clave tiene una frase de contraseña, se te solicitará. 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 al ssh-agent, intenta conectarte a localhost de nuevo usando la misma clave.
ssh -i ~/.ssh/id_rsa_passphrase labex@localhost
Deberías poder conectarte sin que se te solicite una frase de contraseña (tenga o no tu clave una, ya que ahora es gestionada por el agente):
Last login: Mon Jun 9 01:39:49 2025 from 127.0.0.1
[labex@host ~]$
Has utilizado con éxito ssh-agent para gestionar tu clave SSH.
Nota importante: Las variables de entorno de ssh-agent solo están disponibles en la sesión de shell donde lo iniciaste. Si estás en una sesión SSH, necesitas salir de vuelta a tu shell local para usar los comandos ssh-add.
Cierra primero la sesión SSH:
exit
exit
Connection to localhost closed.
[labex@host ~]$
Ahora, para ver las claves cargadas actualmente en tu ssh-agent, puedes usar ssh-add -l:
ssh-add -l
Si el agente se está ejecutando 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 "Could not open a connection to your authentication agent", significa que las variables de entorno del agente no están configuradas en tu sesión actual.
Para eliminar todas las identidades del ssh-agent, usa ssh-add -D:
ssh-add -D
Si el agente es accesible, verás:
All identities removed.
Sin embargo, si ves "Could not open a connection to your authentication agent", significa que el entorno del agente no está disponible en tu sesión actual.
Ahora, si intentas conectarte de nuevo y tu clave tiene una frase de contraseña, se te solicitará porque la clave ha sido eliminada del agente:
ssh -i ~/.ssh/id_rsa_passphrase labex@localhost
Si tu clave tiene una frase de contraseña, verás:
Enter passphrase for key '/home/labex/.ssh/id_rsa_passphrase':
Si tu clave no tiene una frase de contraseña, aún podrás conectarte directamente. Presiona Ctrl+C para cancelar el intento de conexión si se te solicita una frase de 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, es posible que veas:
SSH_AGENT_PID not set, cannot kill agent
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.
Solucionar problemas de conexión SSH
En este paso, aprenderás cómo solucionar problemas comunes de conexión SSH. Cuando las conexiones SSH fallan, puede ser difícil identificar el problema exacto. El comando ssh proporciona opciones de salida detallada (verbose) 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 mostrada.
Comencemos intentando conectarnos a un puerto inexistente en localhost para demostrar el fallo de conexión y ver la salida de depuración.
Primero, intenta con -v (verbose) para conectarte al puerto 2222 (que no debería estar ejecutándose):
ssh -v -p 2222 labex@localhost
Verás una salida similar a esta, indicando que la conexión es rechazada:
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 verbose):
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áxima verbosidad):
ssh -vvv -p 2222 labex@localhost
Este nivel proporciona la máxima cantidad de información de depuración, lo cual puede ser abrumador 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 ningún servidor SSH ejecutándose en el puerto 2222.
Ahora, simulemos un problema común: una clave de host cambiada. 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 intencionalmente la entrada de known_hosts para localhost para hacerla inválida.
Primero, abre el archivo ~/.ssh/known_hosts usando nano:
nano ~/.ssh/known_hosts
Verás múltiples líneas con diferentes tipos de clave:
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=
Elige una de las líneas para modificar. Para este ejemplo, modifiquemos 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 toda la línea u otras partes del archivo.
Por ejemplo, cambia:
...ZN6gG
a:
...ZN6gA
Guarda el archivo presionando Ctrl+X, luego Y para confirmar el guardado y Enter 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 cambiada:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ED25519 key sent by the remote host is
SHA256:h5k1mmPFylpxUCsKx+Mf8rN4wOrk9TmyRfzTvGWRm7A.
Please contact your system administrator.
Add correct host key in /home/labex/.ssh/known_hosts to get rid of this message.
Offending key in /home/labex/.ssh/known_hosts:1
ED25519 host key for localhost has changed and you have requested strict checking.
Host key verification failed.
Esta es una advertencia de seguridad crítica. Si encuentras esto en un escenario del mundo real, deberías investigar por qué cambió la clave del host. Si es un cambio legítimo (por ejemplo, reinstalación del servidor), necesitas eliminar la entrada antigua de known_hosts.
Para solucionar esto, puedes editar manualmente ~/.ssh/known_hosts y eliminar la línea ofensiva, o usar ssh-keygen -R para eliminar la entrada de localhost.
Usemos ssh-keygen -R para eliminar la entrada incorrecta:
ssh-keygen -R localhost
## Host localhost found: line 1
## Host localhost found: line 2
## Host localhost found: line 3
/home/labex/.ssh/known_hosts updated.
Original contents retained as /home/labex/.ssh/known_hosts.old
Ahora, intenta conectarte a localhost de nuevo. Se te solicitará confirmar la autenticidad del host, igual que la primera vez que te conectaste.
ssh labex@localhost
The authenticity of host 'localhost (127.0.0.1)' can't be established.
ED25519 key fingerprint is SHA256:h5k1mmPFylpxUCsKx+Mf8rN4wOrk9TmyRfzTvGWRm7A.
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'localhost' (ED25519) to the list of known hosts.
Last login: Mon Jun 9 01:40:03 2025 from 127.0.0.1
[labex@host ~]$
Ahora estás conectado de nuevo con éxito utilizando la autenticación basada en claves.
Cierra la sesión:
exit
exit
Connection to localhost closed.
[labex@host ~]$
Personalizar configuraciones del cliente SSH
En este paso, aprenderás cómo 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 varias 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
Añade 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 que el usuario labex utilice 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 presionando Ctrl+X, luego Y para confirmar el guardado y Enter para confirmar el nombre del archivo.
Ahora, intentemos conectarnos a localhost usando estos nuevos alias.
Conéctate como labex usando el alias localhost_labex:
ssh localhost_labex
Dado que configuraste IdentityFile ~/.ssh/id_rsa y id_rsa no tiene una frase de contraseña, deberías iniciar sesión sin que se te solicite una contraseña.
Last login: Mon Jun 9 01:54:16 2025 from 47.251.66.143
[labex@host ~]$
Cierra la sesión:
exit
exit
Connection to localhost closed.
[labex@host ~]$
Ahora, conéctate como root usando el alias localhost_root:
ssh localhost_root
Se te solicitará 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 de "Permission denied":
root@localhost's password:
Permission denied, please try again.
root@localhost's password:
Presiona 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 al preconfigurar parámetros de conexión comunes.
Añadamos otra entrada para demostrar cómo especificar un puerto diferente. Aunque localhost utiliza el puerto SSH predeterminado (22), este ejemplo muestra cómo lo configurarías si fuera diferente.
Abre el archivo ~/.ssh/config de nuevo:
nano ~/.ssh/config
Añade la siguiente entrada. Esto crea un alias localhost_port_example que establece explícitamente el puerto en 2222. (Nota: localhost en realidad no escucha 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
You can find some explanations for typical errors at this link:
https://red.ht/support_rhel_ssh
Puedes ver tu configuración SSH actual para ver todos los hosts definidos:
cat ~/.ssh/config
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
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 verse así:
Host localhost_labex
HostName localhost
User labex
IdentityFile ~/.ssh/id_rsa
Host localhost_root
HostName localhost
User root
Guarda el archivo.
Comprender la configuración de seguridad del servidor OpenSSH
En este paso, aprenderás sobre las mejores prácticas de seguridad del servidor OpenSSH examinando la configuración de seguridad actual. Comprenderás cómo funcionan las restricciones de inicio de sesión de root y la configuración de autenticación por contraseña para proteger tu servidor contra el acceso no autorizado.
Nota: En este entorno de laboratorio, examinarás la configuración de seguridad SSH actual y comprenderás diferentes ajustes 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.
Comprender la seguridad del inicio de sesión de root
Permitir el inicio de sesión directo de root vía SSH generalmente se desaconseja porque la cuenta root tiene privilegios administrativos completos. Si un atacante obtiene acceso a la cuenta root, tiene control total sobre tu 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 de inicio de sesión de root y probemos su efectividad.
Primero, inicia sesión vía SSH como usuario labex.
ssh labex@localhost
Deberías iniciar sesión sin contraseña si tu configuración de clave SSH de los 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 los ajustes de seguridad actuales:
sudo cat /etc/ssh/sshd_config | grep -E "^PermitRootLogin|^#PermitRootLogin"
Este comando te mostrará el ajuste actual de PermitRootLogin. Deberías ver algo como:
PermitRootLogin no
Este ajuste significa que el inicio de sesión directo de root vía 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, cierra la sesión SSH actual:
exit
exit
Connection to localhost closed.
[labex@host ~]$
Ahora, intenta iniciar sesión como root en localhost:
ssh root@localhost
Deberías ver un mensaje de "Permission denied", indicando que no se permite el inicio de sesión directo de root (esto puede estar ya configurado en tu 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 eficazmente.
Comprender la seguridad de la autenticación por contraseña
Deshabilitar la autenticación por contraseña obliga a los usuarios a confiar en métodos más seguros como la autenticación basada en claves SSH. Esto reduce significativamente el riesgo de ataques de fuerza bruta contra tu servidor.
Examinemos el ajuste actual de autenticación por contraseña y comprendamos cómo funciona.
Inicia sesión vía SSH como usuario labex (usando tu clave SSH):
ssh labex@localhost
Last login: Mon Jun 9 01:57:32 2025 from 127.0.0.1
[labex@host ~]$
Primero, verifiquemos el ajuste 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 puedes ver, PasswordAuthentication yes está configurado actualmente, lo que significa que la autenticación por contraseña está habilitada. Aunque 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- Este es el ajuste activo que habilita la autenticación por contraseña- Las líneas comentadas proporcionan contexto adicional sobre la configuración de PAM
Esta configuración significa que los usuarios pueden autenticarse usando tanto contraseñas como claves SSH. Para una mayor seguridad, se recomienda deshabilitar la autenticación por contraseña y confiar únicamente en la autenticación basada en claves SSH.
Cierra la sesión SSH actual:
exit
exit
Connection to localhost closed.
[labex@host ~]$
Ahora, verifiquemos que la autenticación basada en claves SSH funcione correctamente mientras la autenticación por contraseña está deshabilitada:
ssh labex@localhost
Esto debería tener éxito sin solicitar contraseña, usando tu 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:
- La autenticación por contraseña está habilitada (
PasswordAuthentication yes) - Los usuarios pueden iniciar sesión tanto con contraseñas como con claves SSH - La autenticación basada en claves SSH funciona correctamente - Hay disponible un método de autenticación más seguro
- El servidor permite ambos métodos de autenticación - Aunque es conveniente, esto puede plantear riesgos de seguridad por ataques de fuerza bruta
- El inicio de sesión de root está deshabilitado - El acceso administrativo requiere una escalada de usuario adecuada
Recomendación de seguridad: Para entornos de producción, considera establecer PasswordAuthentication no para mejorar la seguridad obligando a los usuarios a utilizar únicamente la autenticación basada en claves SSH.
Cierra la sesión:
exit
exit
Connection to localhost closed.
[labex@host ~]$
Has examinado y comprendido con éxito la configuración de seguridad del servidor OpenSSH. El servidor actualmente tiene el inicio de sesión de root deshabilitado (lo que sigue las mejores prácticas de seguridad) y la autenticación por contraseña habilitada (lo que proporciona flexibilidad pero puede requerir consideraciones de seguridad adicionales para entornos de producción). También has 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 vía SSH. Practicaron la autenticación con contraseña y comprendieron la verificación inicial de autenticidad del host.
El laboratorio guió además 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 a proteger el servidor OpenSSH deshabilitando el inicio de sesión de root y la autenticación por contraseña, mejorando su comprensión de las prácticas de acceso remoto seguro.
