• Ejercicios prácticos

1. Autenticación de cliente

conectarse de una máquina A a otra B por ssh, autenticándose por los métodos:
a) password.

Debido a la problemática que tenemos con la configuración de red los ordenadores de la universidad, realizaremos la comprobación mediante un acceso a la propia maquina, es decir utilizando el localhost. Un truco para saber que la conexión esta echa con el servidor, es ejecutar su bash, para poder introducir los comandos. Para ello introduciremos el /bin/bash tras el comando SSH

iker@iker-Studio-XPS-1340:~$ ssh localhost
iker@localhost's password:
Linux iker-Studio-XPS-1340 2.6.35-27-generic-pae #47-Ubuntu SMP Fri Feb 11 22:40:41 UTC 2011 i686 GNU/Linux
Ubuntu 10.10


Welcome to Ubuntu!

0 packages can be updated.
0 updates are security updates.


Last login: Thu Dec 2 11:29:49 2010


b) clave pública con passphrase no nula, siendo iguales usuarios en ambas máquinas. Copiar la clave con scp añadiéndola al final (sin sobreescribir) del fichero authorized_keys.
iker@iker-Studio-XPS-1340:~$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/iker/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/iker/.ssh/id_rsa.
Your public key has been saved in /home/iker/.ssh/id_rsa.pub.
The key fingerprint is:
2d:a1:ff:fa:2d:93:49:b3:42:24:89:88:93:27:d7:27 iker@iker-Studio-XPS-1340
The key's randomart image is:
+--[ RSA 2048]----+
| |
| |
| o o . .. |
|= + E +..o |
| = o.oS . |
| ...o |
| ... = |
| ..*. |
| .+oo. |
+-----------------+


En las distribuciones Debian el propio SSH pone los permisos en solo lectura, para que solo nosotros podamos leerlo. Esto es una medida más de seguridad que se nos da para proteger el servidor.
A continuación se debe copiar la clave pública en la máquina a la que se quiere conectar.


iker@iker-Studio-XPS-1340:~$ scp /home/iker/.ssh/id_rsa.pub localhost:clave.public
iker@localhost's password:
id_rsa.pub 100% 407 0.4KB/s 00:00



Una vez copiada la clave nos conectaremos al servidor para añadir la clave publica.

iker@iker-Studio-XPS-1340:~$ ssh iker@localhost /bin/bash
iker@localhost's password:
cat clave.public >> ~/.ssh/authorized.keys



El fichero authorized.keys de nuestro servidor, será el que nos dirá quién puede conectarse al servidor.



c) clave pública con passphrase no nula, siendo usuarios distintos en cada máquina. Usar ssh-copy-id para pasar la clave.

iker@iker-Studio-XPS-1340:~$ ssh-copy-id 127.0.0.1
iker@127.0.0.1's password:
Now try logging into the machine, with "ssh '127.0.0.1'", and check in:


.ssh/authorized_keys

to make sure we haven't added extra keys that you weren't expecting.


2. Autenticación de servidor

ver la huella (key fingerprint) de un fichero que contenga una clave pública

iker@iker-Studio-XPS-1340:~$ ssh-keygen -lf /home/iker/.ssh/id_rsa.pub
2048 2d:a1:ff:fa:2d:93:49:b3:42:24:89:88:93:27:d7:27 /home/iker/.ssh/id_rsa.pub (RSA)



3.Demostrar el uso de ssh-agent


ssh-agent es un programa para la manipulación de claves privadas. La idea esta en que al iniciar la sesión se ejecute directamente el comando ssh-agent, y que cuando una aplicación solicite una conexión encriptada, lo haga a través del agente, y que evite la interacción con el usuario.
Inicialmente el agente no contiene ningún certificado. Estos pueden agregarse mediante el comando ssh-add, basta con ejecutar:


iker@iker-Studio-XPS-1340:~$ ssh-agent /bin/bash
iker@iker-Studio-XPS-1340:~$ ssh-add
Identity added: /home/iker/.ssh/id_rsa (/home/iker/.ssh/id_rsa)


La idea es que el agente se ejecute localmente. Esto permite que los datos de autenticación (certificados privados) no necesiten estar almacenados remotamente. A su vez, las passphrases nunca son transmitidas a través de la red. Como el agente no transmite claves privadas, el host remoto envía "desafíos" que necesitan de la clave privada para ser resueltos, y son devueltos a quien lo solicitó.


4.Establecer una conexión que reenvíe las X11 de forma encriptada

, comprobándolo mediante el lanzamiento de xclock.

iker@iker-Studio-XPS-1340:~$ ssh -X iker@localhost /bin/bash
xclock





5.Preparar una configuración en base a claves privadas/públicas sin password

5.Preparar una configuración en base a claves privadas/públicas sin password según la cual un comando que emplee ssh con dicha clave pública ejecute automáticamente un script que muestre el comando enviado, y no pueda ejecutar ningún otro. Pista: $SSH_ORIGINAL_COMMAND

El SSH_ORIGINAL_COMMAND nos recogerá el comando introducido. La única finalidad es la de notificar al usuario el comando introducido, sin llegar a ejecutar el comando. Para ello abriremos el archivo authorired.keys e introduciremos la dirección de nuestro script.

command="~/.ssh/comando"

Y el script a ejecutar sera el siguiente:

echo "Comando introducido: $SSH_ORIGINAL_COMMAND"



6.Preparar una configuración en base a claves privadas/públicas sin password según la cual un comando que emplee scp con dicha clave pública sólo pueda hacer un scp copiando ficheros que estén en el servidor hacia el cliente, y no pueda ejecutar ningún otro comando.
Pista: scp -f (opción no documentada)




7.Lanzar un servidor sshd

que escuche por los puertos 22 y 20022 en un equipo A. En otro equipo B dejar un servidor ssh por el puerto 22 y algún servicio por el puerto 80 (ej. apache o netcat en modo escucha). Hacer estas conexiones ssh desde B:

Para realizar esta parte de la practica se han utilizado dos ordenadores conectados mediante un cable de red, un portátil A, donde estará alojado el servidor A, y un equipo B de escritorio, desde donde crearemos los túneles SSH. Antes de empezar la practica deberemos preparar ambos equipos para que puedan funcionar correctamente.

En el equipo A:
Tendremos que ir al fichero /.ssh/sshd.config y añadir el puerto 20022, después del puerto 22. Además también deberemos añadir GatewaysPort yes. Esta última opción nos sustituirá el comando -g que permite aceptar conexiones remotas. Reiniciaremos el servicio ssh y finalmente, para comprobar el funcionamiento correcto de los puertos, visualizaremos mediante netstat que puertos están abiertos, en ese momento.


En el equipo B:
En el equipo B se debe tener un puerto, ya sea de un servidor Apache o un simple netcat, escuchando en el puerto 80. En este caso utilizaremos el netcat como en casos anteriores: nc -l localhost -p 80. Como en el equipo A, en este también debemos comprobar el correcto funcionamiento de los puertos mediante netstat.


a) al puerto 22 de A, con dos túneles inversos:
-Uno que haga que al conectarse en A al puerto 40022 se llegue al 22 de B. (para B utilizar 2022)

Iremos al equipo B, es decir el de sobremesa, y en primer caso crearemos un túnel en el que conectándonos al 40022 de A, se llegue al 22 de B. Ejecutamos el siguiente comando:

escritorio@escritorio-desktop:~$ ssh iker@192.168.2.3 -p 22 -R 40022:192.168.2.2:22
The authenticity of host '192.168.2.3 (192.168.2.3)' can't be established.
RSA key fingerprint is 56:54:88:b9:64:8d:eb:7f:c5:98:03:24:e6:7e:2e:34.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.2.3' (RSA) to the list of known hosts.
iker@192.168.2.3's password:
Linux iker-Studio-XPS-1340 2.6.35-28-generic-pae #49-Ubuntu SMP Tue Mar 1 14:58:06 UTC 2011 i686 GNU/Linux
Ubuntu 10.10


Welcome to Ubuntu!

0 packages can be updated.
0 updates are security updates.


Last login: Mon Mar 7 09:43:06 2011 from iker-studio-xps-1340
iker@iker-Studio-XPS-1340:~$


Como vemos ya se nos sale una shell del propio equipo A. Para ver como la conexión esta establecida en A, miramos mediante el netstat los puertos:

Every 2,0s: netstat -tl Mon Mar 7 18:39:37 2011

Conexiones activas de Internet (solo servidores)
Proto Recib Enviad Dirección local Dirección remota Estado
tcp 0 0 localhost.localdo:mysql *:* ESCUCHAR
tcp 0 0 *:40022 *:* ESCUCHAR
tcp 0 0 *:ssh *:* ESCUCHAR
tcp 0 0 *:20022 *:* ESCUCHAR
tcp 0 0 localhost.localdoma:ipp *:* ESCUCHAR
tcp6 0 0 [::]:www [::]:* ESCUCHAR
tcp6 0 0 [::]:40022 [::]:* ESCUCHAR
tcp6 0 0 [::]:ssh [::]:* ESCUCHAR
tcp6 0 0 [::]:20022 [::]:* ESCUCHAR
tcp6 0 0 iker-Studio-XPS-134:ipp [::]:* ESCUCHAR


Teóricamente si realizaremos una conexión desde el equipo A, por el puerto 40022, tendríamos que obtener una conexión del equipo B. Vemos que el funcionamiento es el correcto ya que nos pide la huella.

iker@iker-Studio-XPS-1340:~$ ssh alumno@localhost -p 40022
The authenticity of host '[localhost]:40022 ([::1]:40022)' can't be established.
RSA key fingerprint is e0:95:3a:4d:78:47:3b:31:78:3e:c5:24:5d:64:bf:b3.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '[localhost]:40022' (RSA) to the list of known hosts.
alumno@localhost's password:
Linux B101610 2.6.32-23-generic #37-Ubuntu SMP Fri Jun 11 07:54:58 UTC 2010 i686 GNU/Linux
Ubuntu 10.04.2 LTS


Welcome to Ubuntu!
Documentation: https://help.ubuntu.com/
Last login: Mon Feb 28 10:43:42 2011 from localhost
alumno@B101610:~$



-Otro que haga que al conectarse en A al puerto 40080 se entre al 80 de B.
A continuación crearemos el segundo túnel que nos permitirá conectarnos en A al puerto 40080 y pasar al 80 de B. Para ello ejecutamos el siguiente comando:

escritorio@escritorio-desktop:~$ ssh iker@192.168.2.3 -p 22 -R 40080:192.168.2.2:80
iker@192.168.2.3's password:
Linux iker-Studio-XPS-1340 2.6.35-28-generic-pae #49-Ubuntu SMP Tue Mar 1 14:58:06 UTC 2011 i686 GNU/Linux
Ubuntu 10.10


Welcome to Ubuntu!

0 packages can be updated.
0 updates are security updates.


Last login: Mon Mar 7 18:59:55 2011 from 192.168.2.3

Si volvemos a realizar la comprobación desde A, conectandonos a través del puerto 40080, esta vez se cierra el netcat que teniamos escuchando en el equipo B, y mostrandonos el siguiente mensaje:

invalid connection to [192.168.2.2] from (UNKNOWN) [192.168.2.2] 57510

Y el mensaje recibido en A, como ya se ha dicho con anterioridad es el siguiente:

iker@iker-Studio-XPS-1340:~$ ssh escritorio@localhost -p 40080
ssh_exchange_identification: Connection closed by remote host


En el equipo A vemos como la conexión esta realizada, ya que los puertos se abren para la escucha

Every 2,0s: netstat -tl Mon Mar 7 19:01:13 2011

Conexiones activas de Internet (solo servidores)
Proto Recib Enviad Dirección local Dirección remota Estado
tcp 0 0 localhost.localdo:mysql *:* ESCUCHAR
tcp 0 0 *:40080 *:* ESCUCHAR
tcp 0 0 *:40022 *:* ESCUCHAR
tcp 0 0 *:ssh *:* ESCUCHAR
tcp 0 0 *:20022 *:* ESCUCHAR
tcp 0 0 localhost.localdoma:ipp *:* ESCUCHAR
tcp6 0 0 [::]:40080 [::]:* ESCUCHAR
tcp6 0 0 [::]:www [::]:* ESCUCHAR
tcp6 0 0 [::]:40022 [::]:* ESCUCHAR
tcp6 0 0 [::]:ssh [::]:* ESCUCHAR
tcp6 0 0 [::]:20022 [::]:* ESCUCHAR
tcp6 0 0 iker-Studio-XPS-134:ipp [::]:* ESCUCHAR



b) al puerto 20022 de A, con un túnel inverso que haga que al conectarse en A al puerto 50022 se llegue al 22 de B.

Este apartado es parecido al anterior, lo unico que cambian son los numeros de puertos. La sentencia a ejecutar en el equipo B para lograr el enunciado seria la siguiente:

escritorio@escritorio-desktop:~$ ssh iker@192.168.2.3 -p 20022 -R 50022:192.168.2.2:22
iker@192.168.2.3's password:
Linux iker-Studio-XPS-1340 2.6.35-28-generic-pae #49-Ubuntu SMP Tue Mar 1 14:58:06 UTC 2011 i686 GNU/Linux
Ubuntu 10.10


Welcome to Ubuntu!
Documentation: https://help.ubuntu.com/
0 packages can be updated.
0 updates are security updates.


Last login: Mon Mar 7 19:00:10 2011 from escritorio-desktop.local
iker@iker-Studio-XPS-1340:~$


Si ahora se comprueba los puertos en escucha en el equipo A vemos, que el puente inverso esta realizado.

Every 2,0s: netstat -tl Mon Mar 7 19:07:22 2011

Conexiones activas de Internet (solo servidores)
Proto Recib Enviad Dirección local Dirección remota Estado
tcp 0 0 *:50022 *:* ESCUCHAR
tcp 0 0 localhost.localdo:mysql *:* ESCUCHAR
tcp 0 0 *:ssh *:* ESCUCHAR
tcp 0 0 *:20022 *:* ESCUCHAR
tcp 0 0 localhost.localdoma:ipp *:* ESCUCHAR
tcp6 0 0 [::]:50022 [::]:* ESCUCHAR
tcp6 0 0 [::]:www [::]:* ESCUCHAR
tcp6 0 0 [::]:ssh [::]:* ESCUCHAR
tcp6 0 0 [::]:20022 [::]:* ESCUCHAR
tcp6 0 0 iker-Studio-XPS-134:ipp [::]:* ESCUCHAR


Como en los otros dos casos anteriores, el host nos deniega el acceso a traves del tunel.

c) Mirar las relaciones padre-hijo entre los procesos de A


8. Configurar un proxy SOCKS con ssh y comprobarlo con un navegador.


SSH también da la opción de utilizarlo como un servidor de socks, para ello tiene la opción D.

iker@iker-Studio-XPS-1340:~$ ssh -D 2000 iker@localhost
Linux iker-Studio-XPS-1340 2.6.35-28-generic-pae #49-Ubuntu SMP Tue Mar 1 14:58:06 UTC 2011 i686 GNU/Linux
Ubuntu 10.10


Welcome to Ubuntu!
Documentation: https://help.ubuntu.com/


26 packages can be updated.
16 updates are security updates.


Last login: Tue Mar 8 13:11:41 2011 from iker-studio-xps-1340

A continuación deberemos ir a la preferencias en el propio navegador, ya que se trata de un proxy no transparente, y debemos configurarlo manualmente, para que el navegador utilice un servidor proxy a traves de sock. En este caso se realiza la muestra a traves de un navegador Mozilla 3.6.14, en ubuntu.





Para comprobar si realmente estamos realizando bien el proxy mediante sock, probamos a deshabilitar el servicio. Si cargamos alguna pagina web, vemos que el servidor proxy, no funciona y no se nos muestra la pagina, en su caso aparece lo siguiente:


Pantallazo-2.png
Pantallazo-2.png


  • Ejercicios teóricos

9. Se desea acceder al correo electrónico de la Escuela desde el exterior por POP3. Pero el único puerto que la Escuela tiene abierto al exterior es el 2200 con el servicio ssh, y además el equipo del servicio sshd puede conectarse con el servidor de correo en el puerto típico POP3.
Definir la conexión desde el exterior.

El problema principal que se plantea es que solo se puede acceder desde fuera mediante SSH y por el puerto 2200 a esta máquina ya que todo los demas puertos teóricamente están cerrados. Para ello una de las opciones y la mas fácil, es crear un tunel directo con el puerto 2200 y a partir de hay redirigir la conexión al servidor de correo POP3. Se haria de la siguiente forma:

ssh -L mipuerto:direccionservidordecorreo:puertoPOP3 direccionservidorSSH -p 2200


10.Se tienen dos redes locales R1 y R2. En R1 hay un servidor web S que sólo tiene abierto el puerto 80 a sus equipos locales, y un equipo proxy P para servir peticiones de ssh al exterior.
a) Indicar la conexión ssh de un equipo E en R2 de modo que haga de proxy ssh hacia R1 para que cualquiera del resto de equipos de R2 pueda acceder a las páginas de S.

La forma más facil sería hacer un tunel directo, saltando las restricciones de los firewires, y conectando la red R2 con R1

ssh proxy -L 80:direccionserveridorweb:80 -g

b) ¿Qué URL habrá de indicarse en los clientes de R2?

Los clientes de R2, deberán pedir las paginas web al equipo E, como si este fuera un servidor, de la siguiente forma:

http://direccionequipoE/paginaweb.html


11.Se tienen dos redes locales R1 y R2. En R1 hay un equipo A1 accesible por vnc (puerto 5900) y otro equipo S1 que es un servidor web. En R2 hay un servidor S2 corriendo sshd a la escucha por el puerto 10001.
a) Indicar el comando de conexión desde S1 a S2 para que los equipos de R2 puedan conectarse tanto al vnc de A1 como a las páginas web de S1.

ssh direccionservidorS2 -p 10001 -R 5900:direccionequipoA1:5900 -R 80:localhost:80 -N -g

b) ¿Qué URL habrá de indicarse en los clientes de R2 para acceder a la web de S1?

http://direccionservidorS2/paginaweb.html

c) Si el servidor web S1 sólo atiende a peticiones que empiecen por http://www.xxx.com/ ¿cuál es una solución posible a hacer en los equipos de R2 para que éstos puedan acceder a páginas servidas por S1?

Solo se deber ir al fichero /etc/hosts y decirle que http://www.xxx.com responde a la direccion IP del servidor S2.


12.Una máquina A tiene su IP pública dinámica, y otra máquina B tiene su IP pública fija. B tiene un daemon ssh escuchando en el puerto 4444. Se desea poder entrar por ssh en A desde B. Para ello, establecer un túnel inverso desde A a B con las siguientes características:
-Una vez establecido el túnel, desde B se deberá poder hacer ssh a A conectándose al puerto 55555 de B.
-La conexión del túnel en A ha de funcionar en background.

Principalemente se tendrán dos opciones para que la conexion funcione en background, la opcion -f o &, el resto del comando será el mismo:

ssh usuario@direccionB -p 4444 -R 55555:localhost:22 -f