ACTIVIDAD 3 GUIA 7 TELNET SSH

JAIME ANDRES DELGADO LEON

INSTRUCTOR
FABIO DELGADO RINCON

FICHA
1753558 G2 G3

SENA
TDIMST
2020
 ACTIVIDADES DE APROPIACIÓN

Luego de revisar los archivos documentos correspondiente a las sesiones, y revisando los documentos
soportes se analizarán las opciones para resolver la situación problema, de una configuración de red
con características descritas a continuación:

La situación problémica está determinada por configurar el Router de manera remota, utilizando la
red como medio de gestión y configuración del dispositivo, para ello se desarrollarán las
configuraciones iniciales por medio de consola a través del PC0 y luego de ello se probará el acceso
desde el PC1 por medio de los protocolos TELNET y SSH.

Para este fin desarrollaremos la configuración física de acuerdo al diagrama, para cada mesa de
trabajo se asignará un Router y uno de los equipos funcionará como PC0 (Para la conexión por
consola) y el otro como PC1 (Para validar la conexión y configuración de los dos protocolos).

Para dar solución a la situación problema, se plantean los siguientes pasos:

 Configurar la conexión del PC0 con el Router mediante consola por medio del puerto serial.

 Configurar la IP de la interface utilizada para conectar el PC1 con el Router.

 Configurar la dirección IP del PC1 que va hacer gestión al Router.

 Verificar la conexión entre el PC1 y el Router

 Configurar TELNET en el Router desde el PC0.

 Verificar la conexión por medio de TELNET desde el PC1, por medio de línea de comandos.
 Ahora vamos a configurar SSH, para ello debemos configurar los siguientes comandos.
 Verificar la conexión por medio de SSH desde el PC1, por medio de línea de
comandos.

Luego de desarrollar los pasos presentados para cada uno de los Routers, y
verificar la conexión, desarrollaremos el siguiente cuestionario.

 ¿Cuáles son las diferencias de configuración de los protocolos TELNET y

SSH?, justifique su respuesta.
RTA/ : TELNET: Es un protocolo de red, Este protocolo establece las bases
necesarias para que podamos conectarnos a un equipo remoto a través
de la red y tomar el control a través de una ventana de terminal. Los
programas que nos permiten esta conexión son conocidos como clientes
de telnet, aunque realmente y de forma general también se les llama
programas de telnet a secas.
Este protocolo se ha utilizado principalmente para conectarse a equipos con
 sistema operativo unix/Linux y así poder realizar operaciones con él sin
necesidad de estar delante de él. Aún hoy se sigue utilizando, aunque es
cierto que hoy en día se utiliza una variante de este protocolo, llamada
SSH, que son las siglas de Secure Shell, y que como se puede intuir es
mucho más segura.
Existen una gran variedad y cantidad de clientes para este protocolo. Uno de
los más conocidos es PuTTY, que además es totalmente gratuito e
incluye una gran cantidad de opciones de configuración para que
podamos configurar el cliente de tal modo que funcione en cualquier
tipo de servidor de Telnet. Personalmente me gusta mucho más el
programa AnzioWin, que también incluye una gran cantidad de opciones
de personalización y es compatible con distintos tipos de terminal, pero
como siempre, estas cosas, van por gustos
Para acceder por telnet a un servidor necesitas que ese servidor de soporte
a telnet y además tener una cuenta de usuario en la máquina a la que te
conectas, Telnet suele escuchar el puerto 23.
Con SSH utilizamos una conexión segura hacia nuestro servidor, con lo
que la información viaja encriptada. En cambio, utilizando Telnet
exponemos toda la información que intercambiamos con el servidor,
con el consiguiente riesgo que esto supone. Es por esto que SSH ha
sustituido al protocolo Telnet.
 ¿Cuál consideraría para utilizar en el caso que deba administrar un
conjunto de Router?, justifique su respuesta.
RTA/: SSH: O Secure Shell, es un protocolo de administración remota que le
permite a los usuarios controlar y modificar sus servidores remotos a través de
Internet a través de un mecanismo de autenticación.
Proporciona un mecanismo para autenticar un usuario remoto, transferir entradas
desde el cliente al host y retransmitir la salida de vuelta al cliente. El servicio se
creó como un reemplazo seguro para el Telnet sin cifrar y utiliza técnicas
criptográficas para garantizar que todas las comunicaciones hacia y desde el
servidor remoto sucedan de manera encriptada.
La imagen de abajo muestra una ventana típica de SSH. Cualquier usuario de
Linux o macOS puede usar SSH en su servidor remoto directamente desde la
ventana del terminal. Los usuarios de Windows pueden aprovechar los
clientes SSH como Putty. Puedes ejecutar comandos shell de la misma
 manera que lo harías si estuvieras operando físicamente el equipo remoto.
Este protocolo es utilizado a diario por los administradores de sistema y con
frecuencia también por desarrolladores. Tiene el potencial para ayudarnos a llevar
a cabo toda clase de tareas en nuestro servidor.

 ¿Qué entiende por RSA para SSH y que ventajas le permite su existencia
y aplicación?, justifique su respuesta.
Una conexión «normal» usando el protocolo SSH es de por sí segura (más segura que una
conexión no cifrada, como telnet) pero presenta, a grosso modo, dos inconvenientes:

1. La contraseña, aún yendo cifrada, viaja por la red siempre que nos conectamos. Cosa que
puede ser peligrosa en el caso que haya alguien capturando el tráfico de nuestra red
(sniffing) y fuese capaz de generar fuerza bruta o descifrar nuestra contraseña (algo
bastante complicado pero no imposible).

2. En el caso de manejar numerosos servidores y conexiones SSH puede ser muy tedioso
tener que estar metiendo contraseñas, almacenandolas, etc. Este método agregaría un plus
de comodidad.

Esto se soluciona con claves RSA, que podemos resumirlo en:

 El cliente envía información sobre su clave pública al servidor.

 El servidor busca en su base de datos la clave pública del cliente y, cuando la
encuentra, le manda al cliente un challenge (desafío), que contiene un número
aleatorio generado y cifrado por el servidor usando la clave pública del cliente.
 El cliente recibe el paquete cifrado, y usa su clave privada para descifrarlo y
devolvérselo al servidor.
 El servidor comprueba que el número devuelto es el que mandó cifrado, por lo tanto
el usuario se a autenticado y se le permite la sesión.

Como véis en ningún momento se envían claves por Internet. Por supuesto, si alguien
accede a nuestro equipo y nos roba la clave privada podría acceder a todos los equipos a los
que tenemos conexión mediante éste método, por lo que es necesario protegerla, para ello
generaremos una clave RSA protegida con clave (valga la redundancia).

El primer paso es acceder al fichero de configuración de sshd en el server

(/etc/ssh/sshd_config). En este caso el servidor será un equipo Kali y el cliente Archlinux.
Buscamos y descomentamos las líneas:
De forma que quede de forma similar a la anterior. Ojo al fichero tras %, que indica dónde
guardaremos las claves RSA autorizadas. A continuación corroboramos que existe el
directorio, en caso de no existir, lo creamos:

Con esta simple configuración inicial, llega el momento de crear nuestra pareja de claves.
Para ello nos disponemos en el cliente (nuestro Archlinux) y tecleamos el comando «ssh-
keygen -t rsa», esto iniciará el breve asistente para la creación de la clave donde elegiremos
el directorio donde almacenarlas (podéis tanto personalizarlo como dejarlo por defecto,
como he hecho yo) y una posible contraseña (como dije anteriormente, algo importante
para protegerla, pero opcional):

El siguiente paso es copiar la clave pública al servidor, para ello usaremos la herramienta
SCP, que pertenece al paquete de SSH y permite copiar contenido usando el protocolo
SSH.

La hemos copiado, como podéis ver, en la carpeta temporal del servidor (/tmp).
Con esto hemos terminado la confiruación tanto de cliente como de servidor, para poder
usar claves RSA al conectarnos. Pero existe un problema, al conectarnos nos sigue pidiendo
contraseña; no la contraseña de usuario, ya que SI usa las claves RSA, sino que nos pide la
contraseña de la propia clave RSA ¿recordáis que le pusimos contraseña para protegerla?.
Hemos añadido una mayor seguridad, pero uno de los inconvenientes que queríamos
solventar era ahorrarnos tener que escribir una contraseña, y así vamos a terminar el post,
claro.

Para evitar tener que poner la contraseña usaremos la utilidad ssh-agent, que se instala junto
a SSH y se ejecuta automáticamente en cada inicio de sesión. Con el comando ssh-add
añadiremos la clave para que esté vinculado a la sesión, de forma que SSH no te pedirá a tí
la clave, sino que lo hará a SSH-Agent.

Una vez hecho, podemos comprobar cómo ya no nos pide ningun tipo de contraseña, y el
acceso al servidor es prácticamente instantáneo, además de más seguro:

Para finalizar, un breve apunte: para añadir más seguridad al servidor, y evitar que puedan
hacerle fuerza bruta, podemos deshabilitar del fichero sshd_config del servidor el acceso
mediante password, quedando así: