TELNET no tiene ningún tipo de cifrado, por lo que todo se transmite en texto plano. SSH está encriptado, por lo que es privado y seguro. Es por eso que se debe usar SSH en lugar de TELNET.
Tanto SSH como TELNET le permiten conectarse a computadoras remotas en red y usarlas como si estuviera sentado frente a ellas. Entonces, ¿cuál es la diferencia entre estos dos venerables protocolos? ¿Realmente siempre hay alguna ventaja en usar SSH sobre TELNET?
TELNET y SSH: La historia del origen
La necesidad es la madre de la invención. Los administradores de sistemas necesitaban una forma de acceder y administrar computadoras que estaban ubicadas físicamente en otro lugar. Si no era práctico 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.
TELNET, abreviatura de teléfonoescribir sobre netoprotocolo de trabajo, fue desarrollado en 1969 como respuesta a ese problema. Mientras la computadora remota fuera accesible a través de la red, permitía que el administrador, o cualquier otra persona autorizada, se conectara a ella y la usara como si estuviera presionando físicamente las teclas del teclado remoto.
SSH se creó mucho más 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ñaron sin ninguna consideración o necesidad percibida de seguridad.
SSH significa secure shBien, para que pueda ver que la seguridad fue un principio rector desde sus inicios. Hoy en día, SSH ha reemplazado casi por completo a TELNET.
TELNET es una pesadilla de seguridad de texto sin formato
El gran problema de TELNET es que utiliza texto sin formato. No encripta nada de su tráfico, incluidos los nombres de usuario y las contraseñas. Cualquier cosa que transmita a lo largo de la red se puede capturar y leer con la mayor facilidad mediante la detección de paquetes. Este es un riesgo de seguridad incluso en una red local, a menos que sea el único usuario. Cualquier usuario puede interceptar el tráfico TELNET y obtener credenciales de inicio de sesión a las que no tiene derecho.
Si la computadora remota está fuera del sitio, lo que requiere una conexión a través 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ás de cincuenta años después, en el panorama de TI actual muy diferente.
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.
¿En qué se diferencia SSH de TELNET?
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ó mucho más tarde que TELNET, el problema se entendió más a fondo y la respuesta se diseñó mejor.
TELNET fue diseñado con privado redes en mente, pero SSH fue diseñado para hacer frente a público redes y la necesidad de mantener la privacidad y la seguridad al transferir datos y realizar conexiones remotas.
TELNET usa el puerto 23 y ese número 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úmero de puerto no obvio hace que sea más difícil para los atacantes identificar el puerto SSH. Si se puede identificar el puerto SSH, es una cuestión trivial montar un ataque de fuerza bruta donde miles de contraseñas obtenidas de violaciones de datos se prueban a su vez mediante un software automatizado.
Aún mejor, SSH puede prescindir de las contraseñas por completo. Puede usar el cifrado de clave pública para autenticarse en computadoras remotas. Las contraseñas nunca se transmiten en absoluto, porque no es necesario enviarlas a la computadora remota. Su encriptación de datos y autenticación de clave SSH significan que SSH puede brindar conexiones y comunicaciones seguras a través de redes inseguras como Internet.
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ñas.
Otra ventaja de usar SSH sobre TELNET es que SSH puede hacer túneles SSH inversos. Esto requiere que el servidor establezca una conexión con la computadora cliente. Hasta que el usuario local desee establecer una conexión con el servidor, se ignora la conexión.
Cuando el cliente quiere conectarse al servidor, el usuario establece una conexión SSH a su propia computadora. SSH envía la conexión por la conexión ya establecida, al servidor. Esto proporciona un túnel privado dentro de la conexión ya encriptada del servidor al cliente.
La única 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.
SSH también ha tenido sus problemas
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ás, los estándares y algoritmos de encriptación cambian con el tiempo y son reemplazados. Como todo software basado en encriptación, a medida que envejecen las versiones SSH, pueden volverse menos seguras. Por eso es importante asegurarse de que está utilizando la última versión de SSH.
La versión de SSH utilizada en la mayoría de las computadoras con Linux es OpenSSH, una implementación 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ía a un atacante solicitar una respuesta del servidor SSL y especificar cuántos datos contener en la respuesta.
Podrían solicitar una respuesta de (digamos) 64 KB cuando la respuesta real no hubiera necesitado más de 64 bytes. La primera secuencia de bytes en esos datos sería la respuesta genuina y esperada, seguida de lo que haya ocurrido en la memoria utilizada recientemente por OpenSSL. Lo que contenían esos datos era suerte, pero podría contener información confidencial, como cookies de sesión y contraseñas, u otra información que permitiera a un atacante adquirir claves privadas, por ejemplo.
Una vez descubierta, en 2014, la vulnerabilidad se conoció como Heartbleed. Se arregló rápidamente 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ón corregida. En otras palabras, cuando las computadoras han sido parcheado. Debido a que muchos administradores tardaron en reaccionar, la aceptación del software reparado fue lenta.
También son preocupantes los dos años entre 2012, cuando se introdujo el error, y 2014, cuando se descubrió y solucionó. Durante esos dos años, todos los servidores SSH que ejecutaban la versión vulnerable de OpenSSL estuvieron en riesgo.
Para ser justos, eso sucedió hace prácticamente una década, y desde entonces ha habido muchos lanzamientos, mejoras, correcciones de errores y revisiones de código.
RELACIONADO: Las mejores formas de proteger su servidor SSH
¿Debe utilizar SSH o TELNET?
Es difícil pensar en una razón por la que necesitaría usar TELNET hoy. Eso no es lo mismo que decir si hay algún escenario en el que sea seguro usar TELNET. En una red autónoma que no está conectada al mundo exterior, y está seguro de que nadie rastreará su tráfico, podría usar TELNET. Pero no hay razón para hacerlo. La compensación de seguridad no se puede justificar.
SSH es más seguro y más flexible: esa es la ventaja de usar SSH sobre TELNET. La implementación de OpenSSH es gratuita para todos los usos, incluido el comercial, y está disponible para todos los sistemas operativos populares.
RELACIONADO: Cómo conectarse a un servidor SSH desde Windows, macOS o Linux