Protocollo per porta seriale remota, con autenticazione e crittografia

Question

Mi piacerebbe rendere disponibile una porta seriale sulla rete. RFC-2217 fornisce estensioni a Telnet per trasportare informazioni aggiuntive sulla porta seriale quali velocità, bit di dati, bit di stop e linee di handshake hardware.

Tuttavia, voglio assicurarmi che non sia liberamente accessibile a chiunque sulla rete, quindi voglio fare autenticazione e crittografia. Telnet è debole per l'autenticazione e non fornisce la crittografia. SSH è generalmente preferito su Telnet.

C'è un protocollo che consente il trasporto della porta seriale tramite SSH, simile a RFC-2217?

Mi rendo conto che un'opzione potrebbe essere quella di tunnel Telnet + RFC-2217 attraverso un tunnel SSH. Ciò è tecnicamente possibile, anche se in termini pratici è un po 'imbarazzante.

Zeroconf

L'altra domanda è: come potrebbe un tale porto essere pubblicizzato con Zeroconf DNS-SD? Per esempio. come può una porta seriale Telnet + RFC-2217, che viene sintonizzata tramite SSH, essere pubblicizzata con Zeroconf? (Telnet plain + RFC-2217 potrebbero essere pubblicizzati come _telnetcpcd._tcp da quello che posso dire.)

Answer 1

Ciò che si desidera è una connessione seriale su LAN protetta.

Il motivo per cui non si trova alcun progetto gratuito che lo faccia è semplice: la maggior parte dei progetti open source separa la sicurezza del livello di trasporto dal protocollo (per buoni motivi). Invece di reinventare la ruota per ogni applicazione, puoi semplicemente riutilizzare il componente di sicurezza (SSH in questo caso) e applicarlo al tuo protocollo non protetto (per esempio, compatibile con RFC-2217).

Utilizzare semplicemente un tunnel SSH o stunnel per proteggere la connessione. Per i client Windows, è possibile utilizzare com2com e per sistemi * nix come ttyd.

com2com, ad esempio, non richiede nemmeno l'avvio manuale dopo l'installazione iniziale, quindi gli utenti devono solo stabilire un tunnel SSH (tramite PuTTY, ad esempio).

• com2com
• socat, utilizzando pty e openssl-listen si può fare più o meno esattamente quello che vuoi (contraddice un po 'quello che ho scritto sopra, perché in realtà non implementare Transport Layer Security)

Answer 2

non sono sicuro che il tunneling SSH è imbarazzante come si pensa:

-Wospite: porta
Richiede che l'input e l'output standard sul client vengano inoltrati per l'hosting sulla porta sul canale protetto. Implica -N, -T, ExitOnForwardFailure e ClearAllForwardings e funziona con Protocol versione 2 solo.

Ecco cosa tunneling breve SMTP sessione assomiglia (input digitato in grassetto):

$ ssh -W mail.server.com:25 blahdiblah@server.com 
220 mail.server.com ESMTP 
Postfix 
ehlo foo.com 
250-mail.server.com 
250-PIPELINING 
250-SIZE 
250-ETRN 
250-AUTH LOGIN PLAIN 
250-STARTTLS 
250-ENHANCEDSTATUSCODES 
250-8BITMIME 
250 DSN 
quit 
221 2.0.0 Bye 

Nessuna impostazione separata un tunnel e poi si collega a quella porta, solo tubazioni di ingresso e uscita dal ssh processi.

Answer 3

SSH fornisce "requesting a pseudo-terminal" con "pseudo-terminal encoded terminal modes". Prevede l'impostazione della velocità di trasmissione, bit, parità, configurazione dei bit di stop. È possibile impostare PARMRK per ricevere errori di framing e condizioni di interruzione. Tuttavia, sembra che al momento il protocollo SSH non contenga alcun comando per impostato su, una condizione di interruzione o per impostare le linee hardware del modem DTR e RTS o per ottenere linee hardware modem DSR, CTS, DCD e RING.

Vedi:

• RFC 4254 - The Secure Shell (SSH) Connection Protocol
• Secure Shell (SSH) Protocol Parameters — IANA