Según ssh.com y Wikipedia, la primera versión e implementación del protocolo SSH se lanzó en 1995. La tarea del autor era desarrollar una alternativa segura a rlogin, telnet y rsh, que luego se utilizaron para la administración remota. Es curioso que la aparición del protocolo SSH fue facilitada por un incidente de seguridad de la información, como resultado de lo cual el atacante recopiló una impresionante base de datos de nombres de usuario / contraseñas de los servidores, simplemente escuchando la red de la universidad y extrayendo paquetes de autenticación (los pares de nombre de usuario / contraseña se transmitieron en forma no cifrada).
El protocolo rápidamente ganó popularidad y, después de un largo período de refinamientos y mejoras, fue estandarizado por el IETF en 2006. Desde entonces, logró convertirse en el estándar de facto para la administración remota de sistemas de consola de texto. Además de la consola de texto en sí, el protocolo proporciona una serie de otras funciones útiles, como la transferencia de archivos y el reenvío de puertos. Se trata del reenvío de puertos y su aplicación no demasiado obvia que se discutirá en este artículo.
El protocolo SSH proporciona dos modos de reenvío de puertos: avance y retroceso. El modo directo le permite abrir un puerto TCP de escucha en el lado del cliente SSH y reenviar todas las conexiones a este puerto al lado del servidor.
Por ejemplo, si se está ejecutando un Servidor de escritorio remoto (RDS) en nuestro servidor SSH, podemos usar el protocolo SSH para conectarnos a este servidor, incluso si la conexión de red directa no es posible (por ejemplo, está bloqueada por un firewall). Así:
El segundo modo de reenvío de puertos, inverso, le permite intercambiar los roles del servidor SSH y el cliente (según se aplica al puerto que se reenvía). En modo inverso, el puerto TCP de escucha se abre en el lado del servidor SSH, y la aplicación que sirve a este puerto está en el lado del cliente SSH. Raramente resulta útil, pero, como regla, muy acertadamente.
Combinando estos dos modos y nuestro ejemplo con un servidor de escritorio remoto, puede obtener esta configuración:
A primera vista, parece redundante. Pero junto con la aparente redundancia, tenemos dos propiedades importantes:
- Lo único que se requiere de la red para que un esquema de este tipo funcione correctamente es garantizar la dirección de red del host donde se encuentra el servidor SSH. Los nodos en los que se ejecutan el servidor y el cliente RDS pueden cambiar sus direcciones de red al menos cada minuto (o incluso pueden tener direcciones en la red privada, solo necesitamos NAT saliente, que a menudo se conoce como la fraseología de "conexión a Internet").
- A pesar de que para nosotros el servidor RDS es accesible desde cualquier lugar en Internet, otros usuarios no pueden conectarse a él (siempre que no haya vulnerabilidades en el servidor SSH). Y dado que el protocolo RDS tiene su propio control de acceso, incluso en el caso de un ataque exitoso al servidor SSH, el atacante también necesitará llevar a cabo un ataque contra RDS. La probabilidad de tener una vulnerabilidad de servidor SSH y una vulnerabilidad de servidor RDS es mucho menor que esa probabilidad para cada componente individualmente.
Si observa detenidamente, en este diagrama puede ver dos redes informáticas independientes. One - transporte - le permite establecer conexiones SSH. Otro, interno, se utiliza para fines aplicados. A partir de esta observación en artículos posteriores, intentaremos sacar algunas conclusiones interesantes, pero por ahora, volvamos a nuestros experimentos.
Conéctese a la computadora de su hogar
En el patio del siglo XXI, la entrega de un paquete de red de Siberia a California toma 0.1 segundos, el mundo entero está enredado en redes de computadoras, y TCP / IP incluso en cepillos de dientes. Parece que con tal conexión de todo con todo, deberíamos haber podido controlar una computadora hace mucho tiempo no solo a través de la presencia física cerca de dispositivos de entrada, sino también de forma remota, a través de la red. Además, hay muchas tecnologías y protocolos para esto. Escritorio remoto de Microsoft, variaciones de VNC en sistemas * nix, soluciones Citrix, miles de ellos ... Sin embargo, pocos de nosotros podemos presumir de la capacidad de conectarnos a la computadora de nuestro hogar desde cualquier parte del mundo utilizando cualquiera de estas tecnologías.
Hay dos razones por las cuales pocos pueden presumir de conectarse a su propia computadora doméstica, y están conectados entre sí. El primero es la ausencia de una dirección de computadora doméstica típica en la red global. Las raíces de este estado de cosas se remontan a 1981, en el que se describió por primera vez el estándar IPv4, que hasta el día de hoy se utiliza (por sí solo, con cambios y adiciones) para abordar la mayoría de los sitios en Internet. Los autores del estándar decidieron que el espacio de direcciones con una capacidad de 3.7 mil millones de direcciones es suficiente para todos los dispositivos en el mundo, pero la realidad resultó ser dura. No se espera que IPv4 Internet esté disponible para septiembre de 2019.
Además, un usuario típico de Internet que no aloja sitios web bien puede disfrutar de todos los beneficios de la civilización sin tener una dirección en la red global, sino que se limita solo a una dirección en una red privada y el proveedor NAT. En otras palabras, para la mayoría de los usuarios de Internet no hay diferencia entre la presencia y la ausencia de una dirección IP global para sus equipos. En tales circunstancias, el número de aquellos a quienes el proveedor emite una dirección IP global en la red global está disminuyendo rápidamente. Como resultado, una computadora doméstica típica se encuentra en una red privada y no tiene una dirección global. Incluso si el proveedor todavía asigna al equipo del usuario una dirección en la red global, este equipo es un enrutador doméstico que realiza NAT desde una red privada doméstica. El usuario, por supuesto, puede "reenviar el puerto" en el enrutador, pero incluso en este mejor caso, la dirección global del enrutador puede cambiar día a día. Sí, hay proveedores que brindan el servicio de "IP estática" por una tarifa modesta, pero en la práctica, en este momento, el usuario se da cuenta de que el juego no vale la pena, y si necesita hacer algo con la computadora de su casa, también puede llamar para llamar
Los más persistentes pueden pasar por esta búsqueda hasta el final y encontrar la segunda razón por la cual abrir el acceso a su computadora a través de Internet es un entretenimiento solo para aquellos que tienen un espíritu fuerte. Esta razón es común: la seguridad de la información. La red global es global, tarde o temprano, alguien del otro extremo del mundo y con malas intenciones llamará a su puerta. Escanear el puerto abierto en el que responde el servidor de escritorio remoto no es una tarea muy difícil y, asegúrese, tarde o temprano, TCP SYN llegará a su puerto súper secreto 32167 desde una aldea china.
Volviendo a nuestro reenvío de puertos exóticos utilizando SSH, notará que sus características eliminan ambas razones.
Construye tu mismo un TeamViewer
Debe hacer una reserva de inmediato, ya que TeamViewer es un gran producto con una gran cantidad de capacidades muy diferentes. Como parte de este artículo, solo recopilaremos para nosotros una forma de conectarnos de manera segura a través de Internet a través del protocolo de Escritorio remoto a una computadora ubicada detrás de NAT. Sin embargo, me atrevo a sugerir que es la conexión a cualquier computadora con acceso a Internet la principal característica distintiva de TeamViewer, por lo que este producto es tan popular. Y es precisamente esa conexión la que podemos implementar con nuestras propias manos, utilizando nuestra configuración SSH de la primera parte del artículo.
Entonces, las condiciones de la tarea: hay una computadora doméstica y una computadora portátil, ambas ejecutan Windows 10. Es necesario hacer posible que la computadora portátil pueda acceder a la computadora doméstica utilizando el protocolo de Escritorio remoto desde cualquier parte del mundo. Nuestro sistema incluirá el servidor de Escritorio remoto de nuestra computadora doméstica, una computadora portátil con un cliente de Escritorio remoto y un servidor SSH. El servidor SSH es el único componente que requiere una dirección IP global y disponibilidad permanente. La opción más fácil para cumplir con estos requisitos es alojar un servidor SSH en la nube. Yandex.Cloud es excelente (principalmente debido a su política de precios), por lo que lo utilizaremos. El resultado es así:
Comencemos preparando la computadora de nuestra casa. Primero, asegúrese de que generalmente se permita el acceso remoto. Esto se puede hacer a través de la pestaña Acceso remoto en la configuración adicional del sistema:
A partir de abril de 2018, Windows 10 ya tiene un cliente ssh entre las utilidades de línea de comandos. Esto nos ayudará a distraernos menos mediante la instalación de diferentes programas y a ponernos en marcha de inmediato. Primero, generamos una clave para SSH. Abra el shell de PowerShell y ejecute 'ssh-keygen'. Cuando se nos solicite la contraseña de la clave, déjela en blanco. Después de generar la clave, muestre su parte abierta en la consola con el comando 'cat $ HOME / .ssh / id_rsa.pub'. El resultado del comando es útil para iniciar el servidor SSH en la nube. Deberías obtener algo como esto:
Necesitamos copiar la parte privada de la clave SSH en la computadora portátil. Esta parte de la clave se encuentra en el archivo '$ HOME / .ssh / id_rsa' (sin el sufijo ".pub"), y podemos copiarlo como un archivo normal. Por ejemplo, usando una unidad flash USB (asumimos que está montada como unidad F :)
copy $HOME/.ssh/id_rsa f:\
Ahora ejecute nuestro servidor SSH. Cree una máquina virtual (VM) en Yandex.Cloud. Para nuestros propósitos, puede elegir una VM "ligera" con 1 vCPU y 0.5 gigabytes de RAM. En la sección de configuración de red, seleccione la red predeterminada con una dirección IP automática. En la sección "acceso", ingrese "inicio" como inicio de sesión, en el campo de entrada de la clave SSH, copie lo que se mostró en nuestra consola en el paso anterior:
Haga clic en "Crear VM" y espere a que se complete. Una vez que se completa la creación de la máquina virtual, necesitamos averiguar su dirección IP:
Necesitaremos la dirección IP de nuestra máquina virtual para ejecutar el cliente SSH en la computadora y computadora portátil del hogar. Ejecútelo en la computadora de esta manera (en este y los siguientes comandos necesita reemplazar 84.201.141.36 con la dirección IP de su VM):
ssh -NR 3389:localhost:3389 home@84.201.141.36
Cuando se nos pregunta sobre la conexión a un servidor desconocido, respondemos "sí". Si entonces no vemos ningún texto en la consola, entonces todo salió bien. Ahora configure la computadora portátil. Copie la clave privada de nuestra unidad flash:
mkdir -Force $HOME/.ssh copy f:\id_rsa $HOME/.ssh/id_rsa
Y ejecute el cliente SSH:
ssh -NL 1025:localhost:3389 home@84.201.141.36
Ahora puede ejecutar el cliente de acceso a escritorio remoto (mstsc.exe) en la computadora portátil, especificando localhost: 1025 como la dirección de conexión. ¡Hurra, funciona!
O casi funciona. Si detiene el proceso SSH en la computadora de su hogar, será imposible conectarse. Necesitamos hacer que este proceso se inicie automáticamente cuando se inicie el sistema, y también se reinicie cuando se desconecte la conexión. Esto se puede lograr, por ejemplo, creando un script de PowerShell y registrándolo como obligatorio para ejecutarse en la Política de grupo al inicio de la computadora. Solo debe tener en cuenta que se lanzará en nombre de la cuenta del sistema, lo que significa que debe asegurarse de que nuestra clave SSH esté disponible para la cuenta del sistema.
Vayamos a la clave primero. Ejecute PowerShell como administrador y ejecute los siguientes comandos:
copy $HOME/.ssh/id_rsa "$(gwmi win32_userprofile | where {$_.SID -eq "S-1-5-18"} | select -ExpandProperty LocalPath)/rds_id_rsa" icacls "$(gwmi win32_userprofile | where {$_.SID -eq "S-1-5-18"} | select -ExpandProperty LocalPath)/rds_id_rsa" /reset
Al mismo tiempo, en la misma ventana de PowerShell, habilite la ejecución del script:
Set-ExecutionPolicy RemoteSigned
Ahora crea el guión real. Abramos nuestro editor de texto favorito (el Bloc de notas también es adecuado) y escribamos este script (recuerde reemplazar la dirección IP del servidor SSH con la que le dio Yandex):
while (1) { & $(get-command ssh |select -expandproperty Path) ` -i "$(gwmi win32_userprofile | where {$_.SID -eq "S-1-5-18"} | select -ExpandProperty LocalPath)/rds_id_rsa" ` -o StrictHostKeyChecking=accept-new -o ExitOnForwardFailure=yes ` -NR 3389:localhost:3389 home@84.201.141.36 Start-Sleep -Seconds 15 }
Guarde el script en el directorio que desee. Finalmente, regístralo para la ejecución automática. Para hacer esto, inicie el Editor de directivas de grupo (Win + R → gpedit.msc) y abra los elementos “Configuración del equipo” → “Configuración de Windows” → “Scripts (inicio / fin)” → “Inicio”. En la pestaña "Scripts de PowerShell", use el botón "Agregar" e indique la ruta a nuestro script guardado.
Haremos lo mismo en una computadora portátil. Primero PowerShell como administrador:
copy $HOME/.ssh/id_rsa "$(gwmi win32_userprofile | where {$_.SID -eq "S-1-5-18"} | select -ExpandProperty LocalPath)/rds_id_rsa" icacls "$(gwmi win32_userprofile | where {$_.SID -eq "S-1-5-18"} | select -ExpandProperty LocalPath)/rds_id_rsa" /reset Set-ExecutionPolicy RemoteSigned
Luego prepararemos un script en un editor de texto (es ligeramente diferente del anterior, pero como antes, reemplazamos la dirección IP con la que Yandex le proporcionó):
while (1) { & $(get-command ssh |select -expandproperty Path) ` -i "$(gwmi win32_userprofile | where {$_.SID -eq "S-1-5-18"} | select -ExpandProperty LocalPath)/rds_id_rsa" ` -o StrictHostKeyChecking=accept-new -o ExitOnForwardFailure=yes ` -NL 1025:localhost:3389 home@84.201.141.36 Start-Sleep -Seconds 15 }
El non-end lo registrará para comenzar al inicio usando "gpedit.msc". Reinicie la computadora y la computadora portátil (para asegurarse de que todo comience correctamente) y listo. Ahora, nuestra computadora doméstica y nuestra computadora portátil están conectadas para siempre (siempre que nuestra máquina virtual en Yandex.Cloud esté encendida y sea accesible).
¿Y qué?
Bueno, ¿no es genial? En cualquier cafetería, en cualquier aeropuerto, puede conectarse a su hogar y ver sus fotos favoritas con los gatos. O bien, en casa con la inclusión de la quinta sinfonía de Beethoven a todo volumen. O interesarse por el éxito de su granja minera. O vea lo que sucede en casa con una cámara web. ¿Pero cuántas aplicaciones tienen la oportunidad de "teletransportarse"? Pero nuestra solución también tiene inconvenientes.
En primer lugar, configurar una conexión no es el proceso más fácil y divertido. Y en caso de que algo salga mal, la depuración es un poco más complicada que la configuración inicial. Por supuesto, este problema se resuelve con perseverancia y paciencia, pero incluso la pequeña cantidad de trabajo que debe gastarse puede generar dudas sobre la viabilidad de los esfuerzos.
En segundo lugar, una máquina virtual en la nube cuesta dinero. En el caso de Yandex, el mínimo con el que puede contar es de 480 rublos por mes. Esto, por supuesto, no es dinero exorbitante, sino el suyo, ganado en el sudor de una persona. Si vale la pena ver imágenes con gatos de este dinero, depende de todos decidirlo por sí mismo, pero es muy posible que todas las ventajas de nuestra solución sean tachadas por su precio.
El problema de los precios puede aliviarse sustancialmente compartiendo los gastos con amigos y personas de ideas afines. Dado que la máquina virtual se utiliza para tareas que no requieren una potencia informática notable, la degradación del rendimiento es extremadamente improbable. Y el efecto económico es notable: si alquila una máquina virtual con diez personas, todos tendrán que pagar solo 48 rublos por mes. Es cierto que, en este caso, la cuestión de la confianza puede violar la armonía: cualquier persona de ideas afines tiene la oportunidad de conectarse a una computadora a través de un servidor SSH. En el caso de que todos tengan contraseñas seguras en sus cuentas, esto no es un problema. Pero, francamente, una contraseña segura para ingresar a la computadora de su hogar es más una excepción que una regla.
Para continuar
Entonces, supongamos que reunimos a 10 personas de ideas afines, configuramos todo como se describió anteriormente y todo funciona para todos. Nuestro club de amantes de las fotos con gatos aprovecha con seguridad la oportunidad de ir a su hogar a través de Internet por solo 48 rublos al mes sin registrarse y sin SMS, todos están felices y felices. La pregunta es: ¿las posibilidades de nuestra "tecnología" se limitan solo a los gatos y es posible usarla para algo más serio?
Por supuesto que puedes. Si en nuestro razonamiento reemplazamos "computadora doméstica" por "construir servidor en la nube" y "computadora portátil" por "computadora de trabajo en la oficina", obtenemos algo digno del título "sistema de acceso a la infraestructura de desarrollo". Y si tenemos una cámara IP en lugar de un servidor de compilación y un puesto de seguridad en lugar de una computadora que funcione, obtenemos un "sistema de videovigilancia".
En ambos casos, sin embargo, será necesario prestar más atención a los problemas de control de acceso. En particular, cuando comparto un servidor SSH por varios usuarios, me gustaría aislar a estos usuarios unos de otros. E incluso con este intercambio, nos vemos obligados a asignar cada recurso separado de cada usuario a un puerto TCP separado y recordar su número. El direccionamiento por números pronto puede volverse bastante tedioso, por lo que me gustaría poder asignar nombres significativos a los recursos. Pero hablaremos sobre cómo mejorar la situación en el próximo artículo.
Mientras tanto, gracias por su atención y por favor comparta sus pensamientos en los comentarios.