Sin más dilación:
Iniciamos la máquina virtual y vamos a comprobar que tengamos el servidor SSH en marcha, para ello inicio una consola o terminal de comandos, ya puede ser en accesorios→ LXterminal, run lxterm, o simplemente apretando simultáneamente CTRL ALT y T:
Ejecutaremos el siguiente comando para averiguar el estado de la conexión:
Hemos visto que el servidor está en marcha así que inicio otra máquina virtual y les pongo a ambas el dispositivo de red en modo bridge y les asigno IP estática a cada uno:
Servidor SSH: 192.168.1.2/24
Cliente: 192.168.1.3/24
Y probamos a conectar desde el cliente al servidor enviándole el argumento de forzar aplicaciones gráficas, para ello procedo de la siguiente manera:
ssh -X bcelaya@192.168.1.2
Y nos dirá al ser la primera vez que no sabe decirnos a ciencia cierta si esa máquina es quien dice ser, esto es normal, le decimos que sí y nos pedirá la contraseña, la escribimos y nos dará la bienvenida al sistema, una vez hecho esto procedo a ejecutar la aplicación xeyes para comprobar si nos ha aceptado el parámetro -X (forzar aplicaciones X11).
La conexión entre cliente / servidor funciona, al ser la primera vez me pregunta si estoy seguro de que este ordenador es quién dice ser, contestaremos que sí para continuar, ya que estamos seguros de que es así
Probamos a ver si nos ejecuta alguna aplicación X11, en este caso hemos decidido probar con xeyes y comprobamos que funciona, el parámetro -X permite forzar la utilización de aplicaciones X11 en el servidor.
Configurando el servicio para denegar login al root:
Por motivos de seguridad es muy probable que no queramos permitir que el root se autentifique en el sistema de forma remota por cuestión de seguridad, para ello en el archivo de configuración ( /etc/ssh/sshd_config ) podemos editar la línea de la sección authentication para negarle el acceso, buscamos la siguiente línea y cambiamos el parámetro a simplemente no:
PermitRootLogin without-password , lo cambiamos a PermitRootLogin no
Hemos editado el archivo de configuración sshd_config para que no permita hacer login al root, cosa que puede ser altamente deseable en términos de seguridad
Ahora probamos a hacer el login y veremos que cuando le pongamos la contraseña nos dirá que acceso denegado, lo cual es lo que queríamos.
Servidor deniega el acceso al cliente con la cuenta root, ya que así lo hemos configurado editando el archivo sshd_config del servidor
Cambiando el puerto de escucha del servidor SSH:
Vamos a proceder ahora a cambiar el puerto de escucha del servidor SSH, éste por defecto utiliza el 22 pero por cuestiones de seguridad o por las que estimemos oportunas podemos configurarlo en otro puerto a nuestra elección.
Para ello, como todo lo que sea parte del servidor, editaremos de nuevo el archivo sshd_config del servidor y cambiaremos el parámetro port, que estará en 22 por el nuevo puerto que le queremos asignar, en este caso nos hemos decantado por el 10022, en mi caso me decido de nuevo por el editor nano, pero esto es a libre elección por supuesto:
sudo nano sshd_config
El archivo sshd_config del servidor nos muestra que está en escucha en el puerto 22, el que usa el protocolo por defecto, editamos la línea y …
...le introducimos el nuevo puerto en el cual queremos que escuche, hemos sustituido el 22 por el 10022, y reiniciamos el servicio para asegurarnos de que procede a usar la nueva configuración
Reiniciaremos el servidor para asegurarnos de que aplique la nueva configuración, esto es muy importante hacerlo cada vez que editemos un parámetro del archivo sshd_config.
Ahora vamos a proceder a conectar con el cliente al servidor, pero le tendremos que indicar en qué puerto tiene que conectar, ya que al no usar el puerto por defecto el cliente necesita que se lo especifiquemos, he procedido de la siguiente manera:
ssh -p 10022 bcelaya@192.168.1.2
Aquí el parámetro -p le indica el puerto al que debe de conectar en el servidor para poder realizar con éxito la conexión.
La conexión se realizó con éxito debido a que le pasamos el puerto de escucha del servidor con el parámetro -p, sino intentaría proceder por el puerto estándar (22) y nos retornaría un mensaje de error ya que el servidor se encuentra escuchando en otro puerto (10022)
Cambiando versiones de protocolo SSH servidor / cliente:
Ahora vamos a jugar un poco con las versiones del protocolo, vamos a poner distintas versiones del protocolo en cliente y servidor y vamos a comprobar que ocurre si intentamos conectar ambos con versiones del protocolo distintas, en el cliente vamos a usar la versión 1 y en el servidor vamos a proceder con la versión 2.
Para ello una vez más procedemos a editar la configuración del servidor (sshd_config) y en este caso en concreto buscaremos el argumento/parámetro Protocol y comprobaremos su valor:
Como está por defecto la versión 2 del protocolo que es la que queremos usar dejaremos esta vez el fichero sin cambios
en este caso está en 2, que es el que queríamos así que lo vamos a dejar intacto y lo que harémos es “forzar” al cliente a usar el protocolo versión 1, y lo haremos de la siguiente manera:
ssh -1 -p 10022 bcelaya@192.168.1.2
Con el parámetro/argumento -1 le estoy indicando al cliente que debe de usar obligatoriamente el protocolo versión 1, como el servidor usa el 2 y son incompatibles nos devuelve el siguiente error y no procede a la conexión, (le he indicado con -p el puerto que hemos editado de escucha, pero voy a volver a poner el 22 por defecto a partir del siguiente punto):
protocol major versions differ: 1 vs 2
Cliente y servidor no se entienden debido al uso de distintas versiones del protocolo SSH (1,2, respectivamente), la conexión no se realiza con éxito
Mostrando fechas de conexión:
En el archivo de configuración del servidor tenemos una línea con el parámetro PrintLastLog yes, esto quiere decir que con este parámetro con la opción activada (yes) nos indicará cuando fué el último login efectuado en el servidor por un cliente, aportándonos la fecha, incluyendo día y hora:
Aquí podemos observar como el cliente conecta con el servidor y éste le da la bienvenida y le indica claramente cuando ha sido la última vez que alguien hizo login en el sistema: Last login Thu (jueves) Nov (noviembre) 13 a las 17:23:26 horas del 2014 desde el cliente 192.168.1.3
Configurando el servidor para el login de usuarios específicos:
Podemos añadir al archivo del servidor el parámetro AllowUsers, con los nombres de usuario seguidos y separados por un espacio a los que queremos permitir el acceso, denegando a los que no lo estén, de hecho, si alguien que no está en la lista y lo intenta le dirá que permiso denegado.
El usuario kakadevaka (perdón por el mal gusto escogiendo nombre) consigue conectar al servidor, ya que él es el único que aparece en el parametro AllowUsers del sshd_config, más tarde lo intenta su compañero bcelaya y …
...no lo consigue, el servidor le deniega el acceso ya que el no se encuentra reflejado en el parámetro AllowUsers…
Redirección X11 en el servidor SSH:
Ahora vamos a jugar un poco con el parámetro X11forwarding, esto permitirá ejecutar aplicaciones X11 desde el servidor remoto.
Para ello volvemos a entrar en el archivo de configuración sshd_config y procedemos a trastear un poco con esta opción, por defecto lo tenemos configurado como sí, así que vamos a dejarlo intacto y probaremos si esto es cierto y funciona, siempre usando el cliente el parámetro -X pues esto es siempre necesario.
Muchas veces esta opción se configura como no, por aumentar la seguridad, aunque esto no está exento de controversia, ya que por lo que he podido leer a grosso modo, esta práctica es muy común aunque el riesgo es bastante mínimo, casi anecdótico, pero en el mundo de la seguridad informática nunca es suficiente.
Conexión SSH entre distintos sistemas operativos:
Ahora vamos a instalar el cliente PuTTy en un sistema windows y a conectar al servidor Lubuntu.
Tras bajarlo, ejecuto el programa, que es un simple exe y ni hace falta instalarlo y le pongo la ip del servidor, pruebo la conexión y accedo al server:
Accedimos al servidor SSH bajo Lubuntu con IP 192.168.1.2 desde el cliente Windows 7 gracias al programa cliente SSH PuTTy, todo un clásico que sigue en forma y muy en uso para las conexiones remotas desde windows
ACT2: Autenticación del cliente:
Por password:
Es el método que hemos usado hasta ahora, es la manera mś común de hacer login en el sistema, que este se encarga de autenticar una vez que el usuario se conecte, el servidor comprobará si el usuario existe en el sistema y le pedirá la contraseña, si el usuario existe y la contraseña proporcionada es la correcta el servidor lo valida permitiendo que se establezca la conexión.
Clave pública con passphrase nula:
Vamos a generar las claves DSA usando SSH versión 2 (que es el más usado y recomendado actualmente). Las claves generadas serán:
- La clave privada que será guardada en nuestra máquina cliente y que opcionalmente puede ser protegida por contraseña.
- La otra es la clave pública que es la que se transfiere al servidor remoto.
Para generarlas lo haremos mediante el siguiente comando:
ssh-keygen -t dsa
El sistema nos pide una passphrase opcional para proteger la clave privada.
Una vez finaliza el proceso en la carpeta /home/usuario/.ssh tendremos los dos archivos nuevos:
- fichero con la clave pública: id_dsa.pub
- fichero con la clave privada: id_dsa
El siguiente paso que debemos de realizar es transferir al servidor la clave pública, agregandola al fichero /home/usuario/.ssh/authorized_keys par que cada vez que conectemos nos identifique con nuestra clave privada.
Hemos generado las claves con el comando ssh-keygen -t dsa, en pantalla se muestra el proceso y el resultado arrojado, ahora procederemos a enviar la pública al servidor para que nos autentique.
Ahora con el comando scp o ssh-copy-id procedemos a enviar la clave pública al servidor de la siguiente manera:
Con scp:
- Entro a mi directorio personal, con cd $home, cd simplemente o cd ~
- Introduzco el siguiente comando:
scp .ssh/id_dsa.pub (usuario)@(servidor):(directorio/archivo)
En nuestro caso sería:
scp .ssh/id_dsa.pub bcelaya@192.168.1.2:.ssh/nueva_clave
Entramos al servidor y transferimos la clave al archivo authorized_keys, para ello seguimos los siguientes pasos:
- ssh (usuario@servidor) en nuestro caso: ssh bcelaya@192.168.1.2
(conectamos al servidor)
- cd .ssh/
(cambiamos a su directorio oculto .ssh)
- cat nueva_clave >> authorized_keys
(el contenido del archivo nueva clave lo añadimos al final del archivo authorized_keys)
- rm nueva_clave
(borramos el archivo el cual contenía nuestra clave por seguridad).
A partir de ahora el usuario se identificará automáticamente, ya que el servidor tiene la clave y la comprueba.
Con ssh-copy-id:
Despues de generar la llave ( ssh-keygen -t dsa), procedemos de la siguiente manera:
ssh-copy-id -i .ssh/id_dsa.pub (usuario)@(servidor)
En nuestro caso sería:
ssh-copy-id -i .ssh/id_dsa.pub bcelaya@192.168.1.2
Clave pública con passphrase no nula:
Esto es idéntico al anterior lo único que cuando nos pregunta por una passphrase, esta vez le introducimos una, en mi caso he decidido poner de passphrase: bruneti
recordemos los pasos:
Generamos la llave:
ssh-keygen -t dsa
Nos preguntará si le queremos asignar una passphrase, esta vez le indicamos una, nos pedirá que la volvamos a introducir para evitar errores tipográficos. Una vez esto repetimos el proceso de enviarlo e introducirlo al final del archivo authorized_keys:
Entro a mi directorio personal, con cd $home, cd simplemente o cd ~
Introduzco el siguiente comando:
scp .ssh/id_dsa.pub (usuario)@(servidor):(directorio/archivo)
En nuestro caso sería:
scp .ssh/id_dsa.pub bcelaya@192.168.1.2:.ssh/nueva_clave
Entramos al servidor y transferimos la clave al archivo authorized_keys, para ello seguimos los siguientes pasos:
- ssh (usuario@servidor) en nuestro caso: ssh bcelaya@192.168.1.2
(conectamos al servidor)
- cd .ssh/
(cambiamos a su directorio oculto .ssh)
- cat nueva_clave >> authorized_keys
(el contenido del archivo nueva clave lo añadimos al final del archivo authorized_keys)
- rm nueva_clave
(borramos el archivo el cual contenía nuestra clave por seguridad).
Cuando procedamos de nuevo a conectar nos identificará por la clave pública y aparte nos pedirá que le indiquemos la passphrase para que podamos acceder al sistema del servidor.
Ahora aunque nos identifica por la clave pública nos pide también que introduzcamos la passphrase como medida adicional de seguridad, en el primer intento la introduzco mal y me la vuelve a pedir, al segundo intento lo introduzco correctamente y me da acceso al sistema del servidor remoto
CONCLUSIÓN:
Esta práctica me ha gustado mucho y la encuentro muy interesante, ya que el protocolo SSH es muy potente y útil, siendo una herramienta que ofrece mil opciones y que a seguro la utilizaré muy a menudo.
Me ha fascinado la gran variedad de opciones que permite sin descuidar la seguridad y lo fácil que es de configurar y de usar.
En definitiva, ojalá todas las prácticas me dejasen tan buen sabor de boca como las de este tema.
No hay comentarios:
Publicar un comentario