Red Hat Linux 7.1: Official Red Hat Linux Reference Guide | ||
---|---|---|
Anterior | Capítulo 11. Protocolo SSH | Siguiente |
Una interfaz de línea de comandos segura es sólo el inicio de las muchas maneras de usar SSH. Dada una cantidad apropiada de ancho de banda, las sesiones X11 se pueden dirigir por un canal SSH. O se pueden asignar conexiones de puerto entre sistemas que previamente eran inseguras a canales SSH específicos usando el reenvío por TCP/IP.
Abrir una sesión X11 a través de una conexión SSH establecida es tan fácil como ejecutar un programa X mientras se está ya ejecutando un cliente X en su host. Cuando un programa X se ejecuta desde un indicador de comandos de shell segura, el cliente y el servidor SSH crean un nuevo canal seguro dentro de la conexión SSH actual, y los datos del programa X se envían a través de ese canal a la máquina de cliente como si usted estuviese conectado al servidor X por medio de una terminal local.
Como podrá imaginar, el reenvío por X11 puede ser muy útil. Por ejemplo, se puede usar el reenvío por X11 para crear una sesión segura e interactiva con el GUI up2date en el servidor para actualizar paquetes en modo selectivo (si posee los paquetes Red Hat Network necesarios instalados en el servidor). Para hacer esto simplemente hay que conectarse al servidor mediante ssh y teclear:
up2date |
Se le pedirá proporcionar la contraseña de root para el servidor. Luego aparecerá el Red Hat Update Agent y usted podrá actualizar sus paquetes en el servidor como si estuviese sentado delante de la máquina.
Sin embargo, los gastos generales de procesamiento requeridos para cifrar y descifrar la información segura que se envía a través del canal, además del ancho de banda extra necesario para enviar datos de aplicaciones X encriptados pueden ser cuantiosos. Es necesario llevar a cabo pruebas adecuadas para asegurarse que el programa X todavía es utilizable, dadas sus condiciones de hardware y ancho de banda particulares.
El reenvío por TCP/IP trabaja con el cliente SSH y pide que un determinado puerto en el lado del cliente o del servidor sea asignado a la conexión SSH existente.
Para asignar un puerto local del cliente a un puerto remoto del servidor, primero hay que saber los números de puerto de ambas máquinas. Hasta es posible asignar dos puertos no estándar, diferentes el uno del otro.
Use el siguiente comando (todo en la misma línea) para crear un canal de reenvío por TCP/IP que escuche las conexiones en el host local:
ssh -L <local-port>:<remote-hostname>:<remote-port> <username>@<hostname> |
Nota | |
---|---|
Configurar un reenvío por TCP/IP para que escuche en puertos inferiores a 1024 requiere acceso a la raíz del mismo modo que iniciar servicios que escuchan en puertos bajo 1024. |
Si por ejemplo desea controlar su correo electrónico en un servidor llamado mail.domain.com usando POP y SSH está a disposición en ese servidor, puede usar este comando para configurar el reenvío por TCP/IP:
ssh -L 1100:mail.domain.com:110 mail.domain.com |
Después de que el reenvío por TCP/IP esté situado entre las dos máquinas puede indicarle a su cliente de correo POP que use localhost como servidor POP y 1100 como puerto para controlar si hay correspondencia nueva. Cualquier petición enviada al puerto 1100 en su sistema será reenviada en modo seguro al servidor mail.domain.com.
Si mail.domain.com no está ejecutando un demonio de servidor SSH pero es posible iniciar una sesión por medio de SSH a una máquina cercana, quizás a través de un cortafuego, puede de todos modos usar SSH para asegurar la parte de la conexión POP que ocurre a través de redes públicas. Para esto es necesario un comando ligeramente diferente:
ssh -L 1100:mail.domain.com:110 other.domain.com |
En este ejemplo, usted está reenviando su petición POP desde el puerto 1100 en su máquina a través de la conexión SSH en el puerto 22 hacia other.domain.com. Luego other.domain.com se conecta al puerto 110 en mail.domain.com para permitirle controlar su correspondencia. Sólo la conexión entre su sistema y other.domain.com es seguro, pero en muchas situaciones esto basta para tener acceso a su información con seguridad a través de redes públicas proporcionando más seguridad de la que tenía anteriormente.
Por supuesto que en este ejemplo y en el precedente hay que ser capaces de autentificarse ante el servidor SSH para desempeñar el reenvío por TCP/IP. Asegúrese de poder ejecutar comandos SSH normales antes de intentar configurar el reenvío por TCP/IP.
El reenvío por TCP/IP puede ser especialmente útil para obtener información en modo seguro a través de cortafuegos de red. Si el cortafuego está configurado para permitir el tráfico SSH a través de su puerto estándar (22) pero bloquea el acceso a través de otros puertos, sigue siendo posible una conexión entre dos hosts usando los puertos bloqueados desviando su comunicación a través de una conexión SSH establecida entre ellos.
Nota | |
---|---|
Sin embargo, esto puede ser muy peligroso. El uso del reenvío por TCP/IP para reenviar conexiones de esta manera permite que cualquier usuario en el sistema del cliente se conecte al servicio al cual usted está reenviando conexiones, que podría ser peligroso si su sistema de cliente se convierte en un sistema expuesto. Controle con el administrador de sistema que administra su cortafuego antes de usar el reenvío por TCP/IP para superarlo. Los administradores de sistemas a quienes les preocupa el reenvío por TCP/IP pueden inhabilitar esta función en el servidor especificando un parámetro No para la línea AllowTcpForwarding en /etc/ssh/sshd_config y luego reiniciando el servicio sshd. |