\n<\/p>\n
TELNET no tiene ning\u00fan tipo de cifrado, por lo que todo se transmite en texto plano. SSH est\u00e1 encriptado, por lo que es privado y seguro. Es por eso que se debe usar SSH en lugar de TELNET.<\/p>\n
Tanto SSH como TELNET le permiten conectarse a computadoras remotas en red y usarlas como si estuviera sentado frente a ellas. Entonces, \u00bfcu\u00e1l es la diferencia entre estos dos venerables protocolos? \u00bfRealmente siempre hay alguna ventaja en usar SSH sobre TELNET?<\/p>\n
La necesidad es la madre de la invenci\u00f3n. Los administradores de sistemas necesitaban una forma de acceder y administrar computadoras que estaban ubicadas f\u00edsicamente en otro lugar. Si no era pr\u00e1ctico o inconveniente para el administrador colocarse frente a la computadora, necesitaban una forma de acceder a la computadora remota que les permitiera emitir comandos como si los estuvieran escribiendo en esa computadora.<\/p>\n
TELNET, abreviatura de tel\u00e9fono<\/strong>escribir sobre neto<\/strong>protocolo de trabajo, fue desarrollado en 1969 como respuesta a ese problema. Mientras la computadora remota fuera accesible a trav\u00e9s de la red, permit\u00eda que el administrador, o cualquier otra persona autorizada, se conectara a ella y la usara como si estuviera presionando f\u00edsicamente las teclas del teclado remoto.<\/p>\n SSH se cre\u00f3 mucho m\u00e1s tarde, en 1995, como una respuesta directa a Telnet y otras soluciones similares. La necesidad esta vez era la seguridad. TELNET, rlogin, FTP y otros protocolos de esa era se dise\u00f1aron sin ninguna consideraci\u00f3n o necesidad percibida de seguridad.<\/p>\n SSH significa s<\/strong>ecure sh<\/strong>Bien, para que pueda ver que la seguridad fue un principio rector desde sus inicios. Hoy en d\u00eda, SSH ha reemplazado casi por completo a TELNET.<\/p>\n El gran problema de TELNET es que utiliza texto sin formato. No encripta nada de su tr\u00e1fico, incluidos los nombres de usuario y las contrase\u00f1as. Cualquier cosa que transmita a lo largo de la red se puede capturar y leer con la mayor facilidad mediante la detecci\u00f3n de paquetes. Este es un riesgo de seguridad incluso en una red local, a menos que sea el \u00fanico usuario. Cualquier usuario puede interceptar el tr\u00e1fico TELNET y obtener credenciales de inicio de sesi\u00f3n a las que no tiene derecho.<\/p>\n Si la computadora remota est\u00e1 fuera del sitio, lo que requiere una conexi\u00f3n a trav\u00e9s de Internet para llegar a ella, el problema se magnifica enormemente. TELNET fue un producto de su tiempo y, para ser justos con ellos, los autores casi con seguridad no esperaban que la gente lo usara m\u00e1s de cincuenta a\u00f1os despu\u00e9s, en el panorama de TI actual muy diferente.<\/p>\n Si bien TELNET merece su lugar en la lista de programas importantes que colectivamente nos ayudaron a llegar a donde estamos hoy, no es algo que debamos seguir usando en el mundo actual.<\/p>\n A primera vista, TELNET y SSH son dos respuestas al mismo problema. Ambos le permiten acceder a una ventana de terminal en una computadora remota y enviarle comandos. Pero debido a que SSH se desarroll\u00f3 mucho m\u00e1s tarde que TELNET, el problema se entendi\u00f3 m\u00e1s a fondo y la respuesta se dise\u00f1\u00f3 mejor.<\/p>\n TELNET fue dise\u00f1ado con privado<\/em> redes en mente, pero SSH fue dise\u00f1ado para hacer frente a p\u00fablico<\/em> redes y la necesidad de mantener la privacidad y la seguridad al transferir datos y realizar conexiones remotas.<\/p>\n TELNET usa el puerto 23 y ese n\u00famero de puerto no se puede cambiar. De manera predeterminada, SSH usa el puerto 22, pero esto se puede configurar y cambiar. Configurar SSH para usar un n\u00famero de puerto no obvio hace que sea m\u00e1s dif\u00edcil para los atacantes identificar el puerto SSH. Si se puede identificar el puerto SSH, es una cuesti\u00f3n trivial montar un ataque de fuerza bruta donde miles de contrase\u00f1as obtenidas de violaciones de datos se prueban a su vez mediante un software automatizado.<\/p>\n A\u00fan mejor, SSH puede prescindir de las contrase\u00f1as por completo. Puede usar el cifrado de clave p\u00fablica para autenticarse en computadoras remotas. Las contrase\u00f1as nunca se transmiten en absoluto, porque no es necesario enviarlas a la computadora remota. Su encriptaci\u00f3n de datos y autenticaci\u00f3n de clave SSH significan que SSH puede brindar conexiones y comunicaciones seguras a trav\u00e9s de redes inseguras como Internet.<\/p>\n De hecho, SSH se puede usar para autenticarse con diferentes servicios, no solo con computadoras remotas que ejecutan un servidor SSH. Por ejemplo, puede acceder a los repositorios de Git alojados en GitHub, GitLab y BitBucket mediante SSH en lugar de contrase\u00f1as.<\/p>\n Otra ventaja de usar SSH sobre TELNET es que SSH puede hacer t\u00faneles SSH inversos. Esto requiere que el servidor establezca una conexi\u00f3n con la computadora cliente. Hasta que el usuario local desee establecer una conexi\u00f3n con el servidor, se ignora la conexi\u00f3n.<\/p>\n Cuando el cliente quiere conectarse al servidor, el usuario establece una conexi\u00f3n SSH a su propia computadora. SSH env\u00eda la conexi\u00f3n por la conexi\u00f3n ya establecida, al servidor. Esto proporciona un t\u00fanel privado dentro de la conexi\u00f3n ya encriptada del servidor al cliente.<\/p>\n La \u00fanica ventaja de TELNET es que utiliza menos ancho de banda. Pero esto no es 1969, donde el ancho de banda era escaso, y SSH tampoco es exactamente un acaparador de ancho de banda.<\/p>\n Aunque SSH supera a TELNET en lo que respecta a la seguridad, debemos recordar que sigue siendo software, y el software puede tener errores. Esos errores pueden generar vulnerabilidades que los ciberdelincuentes pueden explotar. Adem\u00e1s, los est\u00e1ndares y algoritmos de encriptaci\u00f3n cambian con el tiempo y son reemplazados. Como todo software basado en encriptaci\u00f3n, a medida que envejecen las versiones SSH, pueden volverse menos seguras. Por eso es importante asegurarse de que est\u00e1 utilizando la \u00faltima versi\u00f3n de SSH.<\/p>\n La versi\u00f3n de SSH utilizada en la mayor\u00eda de las computadoras con Linux es OpenSSH, una implementaci\u00f3n de SSH que se basa en el kit de herramientas y las bibliotecas de OpenSSL. En 2012, la biblioteca OpenSSL introdujo accidentalmente un error que permit\u00eda a un atacante solicitar una respuesta del servidor SSL y especificar cu\u00e1ntos datos contener en la respuesta.<\/p>\n Podr\u00edan solicitar una respuesta de (digamos) 64 KB cuando la respuesta real no hubiera necesitado m\u00e1s de 64 bytes. La primera secuencia de bytes en esos datos ser\u00eda la respuesta genuina y esperada, seguida de lo que haya ocurrido en la memoria utilizada recientemente por OpenSSL. Lo que conten\u00edan esos datos era suerte, pero podr\u00eda contener informaci\u00f3n confidencial, como cookies de sesi\u00f3n y contrase\u00f1as, u otra informaci\u00f3n que permitiera a un atacante adquirir claves privadas, por ejemplo.<\/p>\n Una vez descubierta, en 2014, la vulnerabilidad se conoci\u00f3 como Heartbleed. Se arregl\u00f3 r\u00e1pidamente en el software. Sin embargo, la vulnerabilidad no desaparece en ese punto. La vulnerabilidad solo se anula por completo cuando todas las computadoras que ejecutan el software vulnerable tienen instalada la versi\u00f3n corregida. En otras palabras, cuando las computadoras han sido parcheado<\/em>. Debido a que muchos administradores tardaron en reaccionar, la aceptaci\u00f3n del software reparado fue lenta.<\/p>\n Tambi\u00e9n son preocupantes los dos a\u00f1os entre 2012, cuando se introdujo el error, y 2014, cuando se descubri\u00f3 y solucion\u00f3. Durante esos dos a\u00f1os, todos los servidores SSH que ejecutaban la versi\u00f3n vulnerable de OpenSSL estuvieron en riesgo.<\/p>\n Para ser justos, eso sucedi\u00f3 hace pr\u00e1cticamente una d\u00e9cada, y desde entonces ha habido muchos lanzamientos, mejoras, correcciones de errores y revisiones de c\u00f3digo.<\/p>\n RELACIONADO:<\/strong> Las mejores formas de proteger su servidor SSH<\/em><\/strong><\/p>\n Es dif\u00edcil pensar en una raz\u00f3n por la que necesitar\u00eda usar TELNET hoy. Eso no es lo mismo que decir si hay alg\u00fan escenario en el que sea seguro usar TELNET. En una red aut\u00f3noma que no est\u00e1 conectada al mundo exterior, y est\u00e1 seguro de que nadie rastrear\u00e1 su tr\u00e1fico, podr\u00eda usar TELNET. Pero no hay raz\u00f3n para hacerlo. La compensaci\u00f3n de seguridad no se puede justificar.<\/p>\n SSH es m\u00e1s seguro y m\u00e1s flexible: esa es la ventaja de usar SSH sobre TELNET. La implementaci\u00f3n de OpenSSH es gratuita para todos los usos, incluido el comercial, y est\u00e1 disponible para todos los sistemas operativos populares.<\/p>\n RELACIONADO:<\/strong> C\u00f3mo conectarse a un servidor SSH desde Windows, macOS o Linux<\/em><\/strong><\/p>\n<\/div>\nTELNET es una pesadilla de seguridad de texto sin formato<\/h2>\n
\u00bfEn qu\u00e9 se diferencia SSH de TELNET?<\/h2>\n
SSH tambi\u00e9n ha tenido sus problemas<\/h2>\n
\u00bfDebe utilizar SSH o TELNET?<\/h2>\n