Utilizzo di SSH come Telnet

Is of my understanding that telnet is an unauthenticated protocol which allows to connect to a remote host and send/receive packets. This is the reason you can use telnet to issue http requests.

Un client Telnet non si cura se si connette a un vero server Telnet oa un qualsiasi socket TCP arbitrario. Poiché Telnet trasmette inalterati tutti i dati (oltre ad alcuni codici di controllo Telnet), è possibile (ab) utilizzare il client per creare una connessione socket raw a un servizio basato su TCP che esegue HTTP, FTP, IMAP, ecc. Nota che la scelta migliore sarebbe utilizzare uno strumento come netcat perché questo in realtà utilizza il TCP non elaborato.

Is also of my understanding that ssh came up as a secure replacement for telnet, given that it authenticates users and provides a secure channel over an insecure network.

È vero. Con SSH è possibile stabilire una connessione autenticata e crittografata. Questo naturalmente richiede un client SSH e un server SSH adatti per funzionare.

If both of above statements are true: 1. telnet allows http requests, 2. ssh is a secure replacement for telnet, why can't i issue http requests using ssh?

Questo perché il tuo client SSH prova a negoziare una connessione sicura con un server HTTP che non sa cosa significhi. Questi sono due protocolli diversi che non funzionano insieme.

Detto questo, se si dispone dell'accesso SSH al server Web, è possibile creare un tunnel SSH e inoltrare la porta 80 per utilizzare l'applicazione Web in modo sicuro su HTTP. Questo potrebbe apparire in questo modo:

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

Un client telnet ti consente di digitare in un socket tcpip non elaborato. Quindi puoi usare un client telnet per lavorare con protocolli testuali come http e alcuni database (e molte altre cose). Non esiste una connessione effettiva tra telnet e http. Quando si utilizza un client telnet come metodo per digitare in un socket, non si utilizza alcuna funzione di telnet.

Chiunque veda il traffico di rete non elaborato può vedere tutto ciò che fai e anche modificare ciò che si invia e riceve. Quindi le persone usano la crittografia. Negli anni '90, tre diversi gruppi di persone stavano inventando allo stesso tempo connessioni di rete sicure. Abbiamo ssl / tls, ssh e ipsec. Hanno tutti problemi, ma tutti possono essere resi sicuri se si utilizzano le ultime versioni e configurate correttamente.

SSH era pensato solo per il terminale Unix sicuro su una rete. Ma può essere usato come tunnel sicuro. TLS era pensato come un tunnel sicuro per le applicazioni. IPSec era inteso come un tunnel sicuro per le apparecchiature di rete, invisibile alle applicazioni.

Nella forma più semplice, è possibile utilizzarne tutti e tre per creare un tunnel sicuro tra due computer e consentire al software client-server non modificato di comunicare attraverso quel tunnel senza essere sicuro che sia ora sicuro (crittografia, integrità, autenticazione, segretezza, ecc.) .

Quindi se usi ssh port forwarding o tls stunnel o ipsec vpn e poi fai richieste http in modo che il traffico passi all'interno di un tunnel ssh o tls o ipsec, stai usando http su ssh o tls o ipsec. Ovviamente, poiché il client http non è a conoscenza del tunnel in questo scenario, non si otterrà l'icona di un lucchetto verde.

Poiché i tre gruppi hanno in mente diversi casi d'uso, il modo in cui i protocolli vengono usati varia molto spesso. Sono solo diverse ottimizzazioni e implementazioni. HTTPS avrebbe potuto essere costruito su protocollo SSH. La shell Secure Unix avrebbe potuto essere costruita su TLS. Si muovono tutti verso djb nacl / libsodium crypto con autenticazione pluggable.

La tua comprensione non è accurata. Le sessioni Telnet possono essere autenticate e l'autenticazione è generalmente avvenuta in chiaro (c'era un telnet Kerberizzato). SSH aggiunge riservatezza e protezione dell'integrità.

Una dichiarazione migliore è che il protocollo SSH è progettato per utilizzare sempre un livello di sicurezza che non è compatibile con i protocolli in chiaro.

Un client telnet può essere utilizzato in diversi modi:

• se il peer non è un daemon telnetd, se funziona più o meno come un semplice netcat e trasferisce il suo input e output standard al / dal socket
• se riconosce il peer come daemon telnet, utilizza il protocollo telnet. In tale modalità, può eseguire l'autenticazione protetta tramite Kerberos e il flusso di dati è normalmente crittografato (nelle versioni recenti) - almeno questo è ciò che man telnet dice

Ricorda inoltre che se si utilizza IPSEC (su IP V6), l'applicazione potrebbe non utilizzare la crittografia poiché è garantita a un livello inferiore.

Detto questo, quando ssh viene presentato come una sostituzione più sicura per telnet, si riferisce solo all'utilizzo classico , che significa simulare un terminale locale su una macchina remota. E ha senso, perché in un ambiente eterogeneo, telnet spesso passa a un flusso non crittografato con credenziali passate in testo non crittografato.

Ma non avrebbe senso cercare di usare un ssh al posto di telnet quando quest'ultimo è usato in modalità netcat.