educación, informática y demás

2311 - Sistemas heterogeneos

Administrando el servidor GNU/Linux en remoto desde GNU/Linux

En este caso práctico dentro de la serie de casos prácticos de sistemas heterogéneos vamos a administrar nuestro servidor GNU/Linux Debian CLI desde otro sistema GNU/Linux Debian con GUI, en concreto con entorno de escritorio XFCE.

Además de conectarnos, vamos a configurar el servidor SSH para que acepte peticiones SSH de un puerto diferente del puerto 22, en concreto 2022, y que solo puedan conectarse a través de ssh los usuarios que pertenezcan al grupo sudo.

Conectando desde GNU/Linux con ssh

En este contexto la red es fundamental así que lo primero que deberíamos hacer es comprobar la dirección IP del servidor y la red a la que está conectado.

Ambos equipos deberían estar conectados a la misma red LAN.

En el sistema Debian servidor CLI tenemos la siguiente configuración de red.

En el sistema con GUI tenemos la siguiente configuración de red.

Las interfaces de red de los sistemas están conectadas lógicamente a redes distintas. Pero además, en nuestro entorno de virtualización, los adaptadores de red están conectados a redes físicas distintas.

Conectando a la misma red física

Conectamos ambos sistemas a la misma red física. En nuestro contexto de virtualización esto consiste en conectar ambas máquinas a la misma red Nat. En este caso práctico vamos a conectarlas a la red NAT 192.168.1XX.0/24, que es ASO2223-Net.

Ahora comprobamos la Red NAT de la interfaz de red virtual de la máquina Debian 12 GUI

Tenemos que cambiar la red NAT

Ahora están los dos adaptadores conectados a la misma red física.

Conectando a la misma red lógica

A continuación nos queda configurar las interfaces de red dentro de los sistemas operativos, en concreto la interfaz de red en el Debian con GUI, para que esté configurado lógicamente dentro de la misma red que el servidor y puedan conectarse a través de la red.

Vamos a configurar la interfaz de red a través de la herramienta gráfica de network-manager.

Esta es la configuración actual

Ahora tenemos que adaptar esta configuración a la nueva red lógica: 192.168.100.0/24. Lo único que vamos a cambiar en este caso práctico es la dirección de red, puesto que este equipo es un equipo cliente y tendrá una dirección IP distinta a las reservadas para servidores.

Ya hemos cambiado la configuración IP de la interfaz de red para que esté conectado lógicamente a la misma red de área local. Ahora para que se apliquen los cambios tenemos que apagar y encender, reiniciar, la interfaz de red.

Después de desconectar, conectamos.

Comprobamos que ha cambiado

Comprobamos que tenemos conexión con el servidor Debian y con Internet.

Nos encontramos con lo siguiente:

Ese ping debería haber funcionado, puesto que la interfaz de red está bien configurada a nivel lógico en el protocolo IPv4 y el ping se lo estamos mandando a la puerta de enlace que en nuestro caso la implementa VirtualBox, debe estar disponible. El problema tiene pinta de ser un problema físico. Vamos a revisar la configuración física de la interfaz de red virtual.

Vamos a configurarla de nuevo y pulsamos Aceptar»

Volvemos a probar desde la terminal si hay conexión

Conexión a través de ssh a nuestro servidor Debian CLI

Cliente SSH

Para conectarnos a un servidor SSH necesitamos un cliente SSH en el equipo origen de la conexión. En este caso, es muy probable que tengamos ya instalado un cliente ssh en Debian 12 XFCE. El programa que nos permitirá iniciar sesión a través de ssh es ssh.

Si no estuviera instalado tan solo tenemos que instalarlo con apt install.

Conectando con el servidor

Vamos a echar un ojo de nuevo a la sintaxis del comando. El único valor obligatorio es destination, que es la dirección, o el FQDN, del equipo destino.

Para conectarnos al servidor tan solo tenemos que escribir la dirección IP de destino.

Podemos ver que estamos conectados al equipo remoto aso00 con el usuario alumno.

Cerramos la sesión con exit.

Conectando con otro usuario

Para conectarnos con un usuario distinto del usuario que estamos usando en el equipo local podemos utilizar en destination la siguiente cadena de texto:

  • nombre_usuario@direccionIP

Dónde nombre_usuario es el nombre de la cuenta de usuario en el equipo remoto con la que queremos iniciar sesión.

Vamos a iniciar sesión con marinapg en la máquina 192.168.100.240.

Si nos fijamos en el prompt del sistema podemos ver que estamos trabajando con el usuario marinapg en la máquina aso00. Si queremos podemos utilizar los comandos whoami y hostnamectl para asegurarnos.

Servidor SSH: Configurando el puerto

Vamos a configurar el servidor SSH para que escuche peticiones a través del puerto 2022 y utilizaremos el cliente ssh para conectarnos a nuestro servidor a través del puerto 2022.

Este cambio de puerto se suele hacer por motivos de seguridad, para dificultar un escaneo de puertos que conozca que servicios tenemos disponibles.

Vamos a echar un vistazo al directorio de configuración de ssh, que posiblemente estará dentro de /etc con el nombre ssh.

Hay dos ficheros que nos llaman la atención porque tienen config en su nombre. El fichero de configuración del servidor es sshd_config. La d nos indica que es el fichero de configuración del demonio (servicio en Unix-like) de ssh.

Si editamos el fichero nos encontramos con que tiene muchos comentarios que comentan valores de algunos de los parámetros de configuración más habituales.

Entre estos parámetros destaca el parámetro Port, que es precisamente el que me piden en este caso.

Si queremos más información acerca de la configuración de SSH podemos consultar la página de manual del fichero sshd_config.

Ahora mismo nos interesa tan solo el parámetro Port.

Configuramos nuestro servidor para que escuche desde el puerto 2022.

Guardamos y vamos a echar un vistazo a la configuración efectiva, sin comentarios, que tiene el fichero de configuración del servido ssh.

Parece que es lo que queremos. Ahora reiniciamos el servidor y comprobamos que está activo.

Hmmmm… aquí ha pasado algo raro. Estamos conectados por ssh al servidor y acabamos de reiniciar el servidor ssh, ¿cómo es posible?.

Lo que ha sucedido es que la conexión que tenemos establecida la está gestionando un proceso independiente que se creó en el momento en que se inicio dicha conexión. Lo que hemos hecho al reiniciar sshd es reiniciar el proceso que está atento a nuevas conexiones a través de ssh.

Vamos a cerrar sesión y tratamos de iniciar una sesión nueva.

Ahora no conecta por el puerto 22 porque está escuchando por el puerto 2022. Vamos a conectarnos usando este puerto.

Se nos ha ido un poco de las manos y hemos iniciado sesión remota desde una sesión remota con marinapg@aso00 en alumno@aso00. Voy a cerrar sesiones e iniciar de nuevo sesión remota segura desde debsrv con marinapg.

Dejar una respuesta