Usando SSH como Telnet

  

Tengo entendido que telnet es un protocolo no autenticado   que permite conectarse a un host remoto y enviar / recibir paquetes.   Esta es la razón por la que puede usar telnet para emitir solicitudes http.

A un cliente Telnet no le importa si se conecta a un servidor Telnet real o cualquier socket TCP arbitrario. Debido a que Telnet transmite todos los datos (además de algunos códigos de control de Telnet) sin alteraciones, puede (ab) usar convenientemente el cliente para crear una conexión de socket sin procesar a un servicio basado en TCP que ejecute HTTP, FTP, IMAP, etc. Tenga en cuenta que la mejor opción sería utilizar una herramienta como netcat porque en realidad usa TCP sin formato.

  

También entiendo que ssh surgió como un reemplazo seguro   para telnet, dado que autentica a los usuarios y proporciona un servicio seguro   canal a través de una red insegura.

Eso es cierto. Con SSH puede establecer una conexión autenticada y encriptada. Por supuesto, esto requiere un cliente SSH y un servidor SSH adecuados para funcionar.

  

Si las dos afirmaciones anteriores son verdaderas: 1. telnet permite solicitudes http,   2. ssh es un reemplazo seguro para telnet, ¿por qué no puedo emitir solicitudes http usando ssh?

Esto se debe a que su cliente SSH intenta negociar una conexión segura con un servidor HTTP que no sabe lo que esto significa. Estos son dos protocolos diferentes que no funcionan juntos.

Dicho esto, si tiene acceso SSH al servidor web, puede crear un túnel SSH y reenviar el puerto 80 para usar la aplicación web de forma segura a través de HTTP. Esto podría ser algo como esto:

$ ssh -L 8080:localhost:80 user@webserver

Un cliente telnet simplemente le permite escribir en un socket tcpip sin formato. Por lo tanto, puede usar un cliente telnet para trabajar con protocolos basados en texto como http y algunas bases de datos (y muchas otras cosas). No hay una conexión real entre telnet y http. Cuando utiliza un cliente telnet como una forma de escribir en un socket, no utiliza ninguna función de telnet.

Cualquier persona que vea el tráfico de red sin procesar puede ver todo lo que hace y también cambiar lo que envía y recibe. Así que la gente usa criptografía. En los años 90, tres grupos diferentes de personas inventaban conexiones de red seguras al mismo tiempo. Tenemos ssl / tls, ssh y ipsec. Todos tienen problemas, pero todos pueden ser seguros si utiliza las últimas versiones y las configura correctamente.

SSH estaba destinado solo para un terminal Unix seguro a través de una red. Pero puede ser utilizado como un túnel seguro. TLS fue pensado como un túnel seguro para aplicaciones. IPSec fue pensado como un túnel seguro para equipos de red, invisible para las aplicaciones.

En la forma más básica, puede usar los tres para crear un túnel seguro entre dos computadoras y permitir que el software cliente-servidor no modificado se comunique a través de ese túnel sin saber que ahora está seguro (cifrado, integridad, autenticación, confidencialidad, etc.) .

Entonces, si usa el reenvío de puertos ssh o stls tls o ipsec vpn y luego realiza solicitudes http para que el tráfico pase dentro de un túnel ssh o tls o ipsec, está usando http sobre ssh o tls o ipsec. Por supuesto, dado que el cliente http no conoce el túnel en este escenario, no obtendrá un icono de candado verde.

Debido a que los tres grupos tenían diferentes casos de uso en mente, la forma en que se usan los protocolos varía con mayor frecuencia. Eso es solo diferentes optimizaciones e implementaciones. HTTPS podría haber sido construido sobre el protocolo ssh. Secure Shell de Unix podría haber sido construido sobre TLS. Todos se mueven hacia djb nacl / libsodium crypto con autenticación conectable.

Su comprensión no es precisa. Las sesiones de Telnet pueden autenticarse, y la autenticación generalmente se realizó de forma clara (hubo un telnet kerberizado). SSH agrega confidencialidad y protección de integridad.

Una declaración mejor es que el protocolo SSH está diseñado para usar siempre una capa de seguridad que no es compatible con los protocolos de texto simple.

Un cliente telnet puede usarse de diferentes maneras:

• si el par no es un demonio telnetd, si funciona más o menos como un simple netcat y transfiere su entrada y salida estándar a / desde el socket
• si reconoce que el par es un demonio telnet, usa el protocolo telnet. En ese modo, puede realizar una autenticación segura a través de Kerberos, y el flujo de datos normalmente está cifrado (en versiones recientes), al menos esto es lo que man telnet dice

También debe recordar que si usa IPSEC (en IP V6), es posible que la aplicación no use cifrado porque está garantizado a un nivel inferior.

Dicho esto, cuando ssh se presenta como un reemplazo más seguro para telnet, solo se refiere al uso clásico , que significa simular un terminal local en una máquina remota. Y tiene sentido, porque en un entorno heterogéneo, telnet a menudo se reduce a un flujo sin cifrar con credenciales pasadas en texto sin cifrar.

Pero no tendría sentido intentar usar un ssh en lugar de telnet cuando este último se usa en modo netcat.