En este artículo vamos a trabajar con ssh para administrar de forma remota y segura sistemas desde línea de comando. Se trata de un artículo de repaso puesto que ya hemos trabajado con SSH en otras ocasiones a lo largo del curso.
SSH es un protocolo de red de nivel de aplicación que permite iniciar sesiones remotas seguras en sistemas remotos. Para proporcionar seguridad SSH cifra la comunicación extremo a extremo.
Para poder conectarnos de forma segura a un sistema remoto necesitamos tener en ese sistema un servidor SSH y un cliente SSH en el sistema local que utilizaremos para conectarnos.
En este caso, vamos a utilizar openssh-server.
Instalando el servidor SSH
si queremos configurar el servidor SSH podemos consultar la ayuda del servidor a través de su página de manual y editar el fichero de configuración /etc/ssh/sshd_config. Ojo! sshd_config no ssh_config.
Hay dos ficheros fundamentales de configuración:
- ssh_config. Fichero de configuración del cliente ssh
- sshd_config. Fichero de configuración del servidor ssh
Para consultar la página de manual utilizamos el comando man seguido de sshd_config
En esta página de manual tenemos información de configuración de este fichero, por ejemplo parámetros de configuración, su uso y valores aceptados.
Configuración de red del servidor
Para podernos conectar utilizando ssh al equipo remoto en el que hemos instalado el servidor SSH. Lo primero que deberíamos saber es la dirección IP del sistema remoto.
Tenemos que conectar los dos sistemas a la misma red LAN o que tengan conexión entre ellas de alguna forma. Con la configuración NAT no podemos conectarlas a través de la red. Vamos a utilizar una de las redes NAT que hemos configurado a lo largo del curso.
En mi caso utilizaré la Red NAT ASO-Proyecto que tiene las siguientes características.
Ahora conectamos la interfaz de red de la máquina virtual SSOO – Debian 12 CLI a esta Red NAT ASO-Proyecto.
Ahora tenemos que configurar el sistema Debian 12 CLI para que utilice los parámetros IP adecuados a esta red. Como este equipo será un servidor debería tener una dirección IP estática dentro de la red 192.168.200.0/24. Le vamos a asignar la dirección de host 254.
Para configurar interfaces de red de forma permanente en un sistema GNU/Linux Debian tenemos que editar el fichero /etc/network/interfaces como root puesto que es una tarea de administración.
Tenemos que configurar la interfaz de red para que utilice una dirección IP estática.
Si no sabemos qué parámetros utilizar o queremos refrescar nuestros conocimientos, podemos consultar la página de manual de interfaces desde otra terminal virtual.
Ahora tenemos que reiniciar la interfaz de red para que cargue los datos que hemos configurado en el fichero interfaces. Para ello utilizamos ifdown e ifup.
Comprobamos la configuración actual de las interfaces de red en el sistema.
El último paso sería comprobar si tenemos conexión a la red LAN y a Internet a través del gateway configurado. Podemos probar si la configuración general es correcta con un solo comando: ping www.educatica.es
Que este ping funcione correctamente significa que:
- El servidor DNS que estamos utilizando está operativo y tenemos conexión con él.
- Estamos conectados correctamente a la red LAN
- Estamos conectados correctamente a la puerta de enlace y ésta tiene conexión con Internet
Vamos a echar un vistazo, por curiosidad al fichero /etc/resolv.conf que es el fichero que contiene la configuración del servidor DNS que se utiliza en el sistema.
Este fichero se ha configurado así al utilizar DHCP la primera vez que se inició el sistema. Cuando teníamos la dirección IP 10.0.2.15 esta dirección ip se asigno a través de DHCP. Con este protocolo de red no solo se obtuvo una dirección IP a utilizar, sino que además se obtuvo la dirección IP de la puerta de enlace así como servidores DNS.
Nosotros vamos a configurar este fichero para que utilice como servidor DNS el primer host de la red, es decir 192.168.200.1
Nos vamos a quedar solo con nameserver 192.168.200.1
Si probamos con una consulta podremos ver quién nos da la resolución de nombres
Cambiando el nombre del sistema
Aunque no es necesario cambiar el nombre del sistema para conectarnos de forma remota y segura, es importante que el nombre de los sistemas represente un poco su función. Vamos a cambiar el nombre del sistema para que utilice como nombre server en lugar de srv03.
Para ello utilizaremos el comando hostnamectl y editaremos el fichero /etc/hosts.
Vamos a echar un vistazo a la página de manual de hostname
Con esto, podemos cambiar el nombre del equipo con la opción hostname seguida del nuevo nombre del sistema.
Vamos a ver si ha funcionado
El último paso sería editar el fichero /etc/hosts para actualizar la referencia del nombre srv03 con la dirección IP de localhost…
Vamos a probar a ejecutar de nuevo hostanamectl para mostrar el nombre del equipo
Sin embargo, en el prompt del sistema sigue apareciendo el antiguo nombre del equipo: srv03.
Para actualizar esta información tenemos que iniciar una nueva sesión en el sistema, cerrando previamente esta.
Conexiones remotas con el cliente SSH
Ya hemos configurado el sistema GNU/Linux Debian 12 CLI con una dirección IP estática dentro de la Red LAN privada 192.168.200.0/24. Ahora vamos a utilizar nuestro sistema GNU/Linux Debian 12 con escritorio XFCE para administrar de forma remota y segura el servidor.
Lo primero que deberíamos comprobar es que el sistema Debian 12 XFCE está conectado físicamente a la misma red LAN que el servidor. Con Virtual Box, comprobamos la configuración de su interfaz de red virtual.
Ahora vamos a comprobar si desde el sistema Debian 12 XFCE tenemos conexión con el equipo server.
No tenemos conexión. De hecho, según la información de configuración de las interfaces de red la interfaz de red enp0s3 no está configurada….
Lo primero que comprobaría en un sistema real es que esté físicamente conectada la interfaz de red con un punto de conexión que lleve al switch. En Virtual Box, comprobamos que el cable de red esté conectado.
En mi caso no estaba conectado. Así que lo conectamos y esperamos un poco a que el sistema detecte la conexión con el cable de red y configure la interfaz de red.
Comprobamos si tenemos conexión con el equipo server.
Tenemos conexión con el servidor.
Ahora queremos que cuando escribamos ping server se haga un ping al equipo con dirección IP 192.168.200.254.
Para ello editamos el fichero /etc/hosts que contiene resolución estática y local de nombres. Este fichero ya lo hemos editado al cambiar el nombre del sistema server. Ahora vamos a repetir el proceso pero para añadir un nombre asociado con una dirección IP, en nuestro caso el nombre server lo asociaremos con la dirección IP 192.168.200.254.
Este fichero es el precursor de los sistemas de nombres o servicio DNS, que hoy en día se sigue utilizando de forma local.
Si ahora escribimos ping server, el sistema resolverá el nombre server con la dirección IP 192.168.200.254.
Ahora que tenemos configurada la red y hemos asignado un nombre a la dirección IP del equipo servidor, vamos a conectarnos a través de ssh.
Ahora estamos en la máquina server no en la máquina fileserver 🙂
Desde el sistema server, vamos a mostrar información de usuarios conectados al sistema utilizando el comando w.
También podríamos utilizar who.
Es más, vamos a buscar procesos que contengan en su nombre la cadena ssh
Para cerrar la sesión remota, ejecutamos el comando exit.
Veamos a de nuevo los procesos en la máquina server
Iniciando sesión remota con un usuario concreto
Vamos a ver qué usuarios tenemos en el sistema server
Vamos a iniciar sesión remota con el usuario marinapg en el sistema server desde el sistema fileserver.
Si ejecutamos w nos mostrará la conexión
Vamos a hacer una prueba.. ¿qué sucederá con la sesión de marinapg si matamos los procesos 1425 y 1450?
En la terminal del sistema XFCE nos encontramos el siguiente mensaje.
Es decir, se ha cerrado abruptamente la sesión remota con ssh.
Iniciando sesión remota utilizando criptografía asimétrica
Cada ves que tenemos que iniciar sesión en un equipo remoto tenemos que escribir el nombre del usuario que vamos a utilizar para iniciar sesión, si es distinto del usuario que estamos utilizando, y escribir la contraseña de acceso.
Para agilizar los accesos a sistemas remotos a los que solemos conectarnos podemos utilizar un par de claves pública y privada que nos facilitarán conectarnos desde un cliente concreto a un sistema remoto ya configurado. Es decir, podemos configurar nuestra cuenta de usuario en el sistema remoto para que nos autentifique utilizando criptografía asimétrica o un par de claves pública y privada.
El primer paso será contar con un par de claves pública y privada. Si no las tenemos, vamos a generarlas utilizar ssh-keygen. Es muy recomendable cifrar la clave privada con una contraseña que solo nosotros conozcamos, no obstante, con fines académicos o si queremos agilizar el acceso a un equipo remoto sin tener que escribir ninguna contraseña más allá de la que escribimos al iniciar sesión, deberíamos dejar la contraseña de protección de la clave privada en blanco.
Todo esto viene porque la clave privada de un par de claves pública / privada en criptografía asimétrica debemos protegerla al 100% y no dejar nunca que nadie pueda utilizarla excepto nosotros. De ahí que, una vez generado el par de claves pública y privada, se suela cifrar la clave privada para dotarla de seguridad ante accesos indebidos.
Hemos creado el par de claves, vamos a ver dónde se han almacenado.
Para poder iniciar sesión de forma remota sin tener que escribir contraseña, dejando que la autenticación se lleve a cabo utilizando criptografía asimétrica, debemos configurar nuestra cuenta de usuario en el servidor. Para ello, tendríamos que copiar la clave pública del equipo cliente al servidor. Podemos realizar este proceso utilizando el comando ssh-copy-id pasando el nombre de usuario y el equipo por parámetro.
Primero veamos en la cuenta del usuario alumno en el equipo server si tenemos el directorio .ssh.
Actualmente no existe ese directorio. Vamos a ejecutar el comando ssh-copy-id para que se copie la clave pública al equipo remoto server dentro de la cuenta alumno. Para ello, le pasamos como parámetro alumno@server
Si volvemos a mostrar el directorio .ssh dentro del directorio personal del usuario alumno en la máquina server veremos como ahora si hay algo.
Veamos el contenido del fichero.
Es un fichero que contiene una clase rsa de ssh, en concreto la clave pública del usuario alumno@fileserver.
De esta forma, ssh-copy-id ha copiado la clave pública en el directorio .ssh de la cuenta alumno@server. Ahora, el servidor ssh puede utilizar esta clave pública para autentificar al usuario alumno@fileserver con la clave privada que está almacenada en filserver.
Vamos a iniciar sesión remota en server con la cuenta alumno.
Configurar el puerto de escucha
SSH utiliza por defecto el puerto 22. No obstante, para dotar de un poco más de seguridad a este servicio habitualmente se suele cambiar el puerto 22 a otro puerto distinto para enmascararlo. De esta forma, un atacante no sabe en qué puerto está escuchando el servicio ssh en la máquina remota.
Vamos a aprender a cambiar el puerto del servidor y configurar nuestro cliente para que cuando nos conectemos a la máquina remota server automáticamente utilice el puerto seleccionado.
Configurando el puerto de escucha en el servidor
Para configurar el puerto de escucha editamos el fichero de configuración sshd_config. Podemos acordarnos de la d de sshd_config recordando que los servicios en Unix-Like se llaman daemons o demonios.
Ahora buscamos el parámetro de configuración Port.
Descomentamos la línea y cambiamos el 22 por el puerto seleccionado: 44022
Guardamos los cambios y salimos. Para terminar, reiniciamos el servicio para asegurarnos de que se cargan los cambios.
Si ahora tratáramos de conectarnos desde el equipo remoto…
Aquí surgen varias dudas:
- Si hemos reiniciado el servicio ssh estando conectados a ssh, ¿por qué ha seguido la sesión abierta?. Porque cuando se abre una sesión ssh, se crean procesos independientes para esa sesión ssh. Al reiniciar lo que hemos hecho es reiniciar el proceso que escucha a nuevos inicios de sesión.
- Ahora nos dice que no se puede conectar al puerto 22 si estamos conectados hace un momento. Esto es así porque hemos cambiado el puerto de escucha al 44022, no obstante existía ya una conexión abierta y funcionando con el puerto 22. Una vez hemos salido, esa conexión se cierra y solo queda el proceso de espera de inicios de sesión remota a través del puerto 4402.
¿Cómo nos conectamos con el cliente ssh? Tenemos que utilizar la opción -p seguida del número del puerto a utilizar.
Configurando el cliente
Sin embargo, esto puede resultar un poco pesado. Si vamos a conectarnos a alumno@server de forma periódica, estaría bien poder configurar el cliente ssh para que utilice por defecto el puerto seleccionado en el servidor.
El fichero de configuración del cliente ssh está en /etc/ssh/ssh_config. Ojo! este fichero no tiene la «d» detrás de la cadena de texto ssh.
Editamos el fichero en el equipo cliente, es decir fileserver.
Nos encontramos con un parámetro llamado Host que nos permite configurar un host concreto. Si nos fijamos como valor detrás de Host encontramos el comodín * que significa que la configuración que hay a continuación se aplicará a todos los hosts de destino.
Las configuraciones se aplican en el orden en el que están en el fichero de configuración. Así que, vamos a añadir una configuración específica para el Host Server justo encima de la configuración Host *
Guardamos, salimos y probamos
Vamos a ver qué pasaría si utilizamos la dirección IP del equipo remoto
Para solucionar este problema, vamos a cambiar la configuración de host para que la configuración se aplique tanto a la dirección IP de la máquina como a su nombre
Así que volvemos a editar el fichero de configuración del cliente
Hemos añadido al patrón de la dirección de host remota la dirección IP del equipo concreto remoto.
Vamos a echar un vistazo al fichero known_hosts de nuestra cuenta alumno@fileserver, es decir en el equipo con xfce.
Ejecutando aplicaciones con GUI
Vamos a probar a lanzar una aplicación que tenga interfaz gráfica como mousepad en el servidor. Lo primero que tendríamos que hacer es instalar mousepad en el equipo server.
Podemos hacerlo…
No obstante, nos gustaría no tener que escribir la opción -X cada vez que nos conectemos a este equipo server y queramos ejecutar aplicaciones con GUI
Configuramos la sección de los hosts server y 192.168.200.254 para que utilicen la opción de redirección de X11. Si no tenemos claro para qué vale esa opción o queremos tener más información lo ideal es que consultemos la página de manual del fichero ssh_config
Configuración del cliente ssh propia de cada usuario
Hasta ahora toda la configuración del cliente ssh de nuestro sistema la hemos hecho a través de la edición del fichero /etc/ssh/ssh_config como root. Nos surge la duda de si un usuario normal, sin privilegios de administración, podría tener una configuración propia del cliente ssh sin tener que editar este fichero.
Podemos realizar una configuracion personalizada para un usuario a través de un fichero de configuración específico cuyo nombre será config y estará dentro del directorio .ssh en el directorio personal de cada usuario: ~.ssh/config
Vamos a probar todo esto con el usuario marinapg
Para este usuario no existe ni siquiera el directorio .ssh, vamos a crearlo como marinapg.
Creamos una sección Host propia para el host server
Esto funcionaría de cualquier manera porque la configuración general de ssh en este sistema es la misma. Lo que vamos a hacer, solo un momentito y para probar, es comentar la configuración general.
Ahora nos conectamos desde la cuenta de marinapg
Ha funcionado!!! Si salimos y tratamos de iniciar sesión remota con alumno, fallará.
Esto es así porque hemos comentado, eliminado temporalmente, la configuración general del cliente ssh.
Vamos a dejarlo como estaba O:)
Dejar una respuesta