Mosh

Q: Chi ha scritto Mosh?

Mosh è stato scritto da Keith Winstein, insieme a Anders Kaseorg, Quentin Smith, Richard Tibbetts, Keegan McAllister, e John Hood.

D: Perché un altro protocollo di terminale remoto?

La latenza pratica su Internet è in aumento, con l’aumento del bufferbloat e dei sofisticati collegamenti wireless che ottimizzano il throughput sul ritardo. E il roaming è più comune che mai, ora che i computer portatili e i dispositivi palmari hanno ampiamente soppiantato i desktop. SSH è ottimo, ma frustrante da usare quando si vuole cambiare indirizzo IP o si ha un collegamento a lungo ritardo o una connessione sospetta.

Inoltre, TELNET aveva alcune buone cose a suo favore – una modalità local-echo e un terminale virtuale di rete ben definito. Anche oggi, SSH non supporta adeguatamente UTF-8 end-to-end su un sistema POSIX.

D: I principi di mosh sono rilevanti per altre applicazioni di rete?

Pensiamo di sì. I principi di progettazione che Mosh rappresenta sono conservativi: avvertire l’utente se lo stato visualizzato non è aggiornato, serializzare e fare il checkpoint di tutte le transazioni in modo che se non ci sono avvertimenti, l’utente sa che ogni transazione precedente ha avuto successo, e gestire gli eventi attesi (come il roaming da una rete WiFi all’altra) con grazia.

Questi non sembrano troppo controversi, ma applicazioni di lusso come Gmail-in-Chromium o su Android si comportano ancora in modo atroce su connessioni sospette o dopo aver cambiato indirizzo IP. (Vi è mai capitato che Gmail lasciasse un messaggio di posta elettronica in “Invio…” per dieci ore mentre recuperava allegramente nuova posta e non indicava alcun tipo di errore? Anche a noi). Pensiamo che ci possa essere un considerevole margine di miglioramento in molte interfacce utente di rete dall’applicazione di questi valori.

D: Ricevo “mosh richiede un locale UTF-8.” Come posso risolvere il problema?

Per diagnosticare il problema, esegui locale sul terminale locale e ssh remotehost locale. Per usare Mosh, entrambi i lati della connessione dovranno mostrare un locale UTF-8, come LC_CTYPE="en_US.UTF-8".

Su molti sistemi, SSH trasferirà le variabili d’ambiente relative al locale, che sono poi ereditate da mosh-server. Se questo meccanismo fallisce, Mosh (a partire dalla versione 1.2) passerà le variabili da solo. Se nessuno dei due meccanismi ha successo, puoi fare qualcosa come

mosh remotehost --server="LANG=en_US.UTF-8 mosh-server"

Se en_US.UTF-8 non esiste sul server remoto, puoi sostituirlo con un locale UTF-8 che esiste. Potrebbe anche essere necessario impostare LANG localmente per il beneficio di mosh-client. È possibile che la macchina locale e quella remota abbiano bisogno di nomi di locale diversi. Vedi anche questo ticket GitHub.

D: Cosa significa il messaggio “Niente ricevuto dal server sulla porta UDP 60003”?

Questo significa che mosh è stato in grado di avviare mosh-server con successo sulla macchina remota, ma il client non è in grado di comunicare con il server. Questo generalmente significa che qualche tipo di firewall sta bloccando i pacchetti UDP tra il client e il server. Se hai dovuto inoltrare la porta TCP 22 su un NAT per SSH, allora dovrai inoltrare anche le porte UDP. Mosh userà la prima porta UDP disponibile, iniziando dalla 60001 e fermandosi alla 60999. Se hai solo una piccola manciata di sessioni contemporanee su un server, allora puoi inoltrare una gamma più piccola di porte (ad esempio, da 60000 a 60010).

Strumenti come netstat, netcat, socat e tcpdump possono essere utili per il debug di problemi di rete e di firewall.

Questo problema può anche essere il risultato di un bug in glibc 2.22 che colpisce i programmi che collegano con protobuf e utempter e usano flag di hardening aggressivi del compilatore. (voce del bugtracker di glibc, così come la voce del bugtracker di Mosh.) Il problema causa il segfault immediato di mosh-server all’avvio. Crediamo di aver risolto questo problema in Mosh 1.2.6, ma per favore segnalate un bug se trovate il contrario.

D: Perché insistete su UTF-8 ovunque?

Non siamo davvero fanatici dell’UTF-8. Ma è molto più facile implementare correttamente un emulatore di terminale che cercare di fare la cosa giusta in una varietà di difficili casi limite. (Questo è ciò che GNU screen cerca di fare, e nella nostra esperienza porta ad alcune situazioni molto difficili da debuggare). Quindi mosh semplicemente non si avvia fino a quando l’utente non ha configurato tutto per un percorso UTF-8-clean. Può essere fastidioso, ma probabilmente riduce anche la frustrazione lungo la strada. (Sfortunatamente un vt220 a 8 bit e un vt220 UTF-8 sono tipi di terminale diversi e incompatibili; l’UTF-8 va sotto la macchina a stati vt220.)

D: Come posso usare una porta SSH diversa (non 22)?

A partire da Mosh 1.2, puoi passare argomenti a ssh in questo modo:

mosh remotehost --ssh="ssh -p 2222"

o configurare un alias di host in ~/.ssh/config con una direttiva Port. Mosh rispetterà anche questo.

D: Ricevo ‘mosh-server not found’.

Assicurati che mosh sia installato sul client, e che mosh (o almeno mosh-server) sia installato sul server a cui stai cercando di connetterti. Inoltre, ci si aspetta che il server sia disponibile sul login di default del tuo server PATH, che di solito non è vero sui server OS X e BSD, o se installi mosh-server nella tua home directory. In questi casi vedi le istruzioni “Server binary outside path” nella sezione Usage, sopra.

D: SSH si autentica usando i ticket Kerberos, ma Mosh mi chiede una password.

In alcune configurazioni, SSH canonizza l’hostname prima di passarlo al plugin Kerberos GSSAPI. Questo si rompe per Mosh, perché la ricerca iniziale del DNS in avanti è fatta dallo script wrapper di Mosh. Per aggirare questo problema, invocare Mosh come

mosh remotehost --ssh="ssh -o GSSAPITrustDns=no"

Questo spesso fallirà su una configurazione DNS round-robin. In questo caso è probabilmente meglio scegliere un host specifico dal pool round-robin.

D: Perché il buffer di scrollback del mio terminale è incompleto?

Mosh sincronizza solo lo stato visibile del terminale. Stiamo monitorando questo problema; vedi questo problema e gli altri che sono collegati da lì. Per ora, il workaround è usare screen o tmux sul lato remoto.

D: Come ottengo 256 colori?

Assicurati di eseguire mosh in un terminale che si pubblicizza come capace di 256 colori. (Questo generalmente significa che TERM sarà xterm-256color o screen-256color-bce.)

D: Come faccio a digitare C-^, il carattere di escape predefinito di Mosh?

Sulle tastiere con il layout degli Stati Uniti, questo può essere digitato come Ctrl-Shift-6, o spesso come Ctrl-6 (questo dipende dal tuo sistema operativo e dall’emulatore di terminale). Sulle tastiere non americane, è spesso difficile trovare il tasto giusto, e a volte non è disponibile affatto. Se la vostra tastiera ha un tasto morto con un accento circonflesso, questo non è probabilmente il tasto giusto. Ctrl-6 a volte funziona, però. Se non sei in grado di digitare questo carattere, dovrai impostare la variabile MOSH_ESCAPE_KEY; vedi la pagina man di Mosh per i dettagli.

D: Come posso fare in modo che il server pulisca automaticamente le sessioni inattive?

Si prega di vedere le voci per MOSH_SERVER_NETWORK_TMOUT e MOSH_SERVER_SIGNAL_TMOUT nella pagina man di mosh-server(1).

D: Qual è il record di sicurezza di Mosh finora?

Mosh 1.0 è stato rilasciato nel marzo 2012. A partire dal rilascio di Mosh 1.3.2 nel luglio 2017, per quanto ne sanno gli sviluppatori:

  • Negli ultimi quattro anni, nessuna vulnerabilità di sicurezza di qualsiasi tipo (maggiore o minore) è stata riportata in Mosh.
  • Nessuna vulnerabilità di sicurezza maggiore è mai stata segnalata in Mosh. Noi definiamo le vulnerabilità di sicurezza maggiori come l’escalation dei privilegi, l’esecuzione di codice in remoto, il denial-of-service da parte di terzi, ecc.
  • Due problemi di denial-of-service sono stati scoperti e risolti nelle versioni del 2012. Un problema permetteva a un mosh-server di far spendere al themosh-client un eccesso di CPU (CVE-2012-2385, risolto in Mosh1.2.1, rilasciato a maggio 2012). Un altro problema permetteva al serverhost di indurre il mosh-client ad inviare datagrammi UDP ad un indirizzo errato, sventando il suo tentativo di connessione (risolto in Mosh 1.2.3, rilasciato nell’ottobre 2012).

D: Come si confronta la sicurezza di Mosh con quella di SSH?

Pensiamo che il design conservativo di Mosh significhi che la sua superficie di attacco si confronta favorevolmente con sistemi più complicati come OpenSSL e OpenSSH. Il track record di Mosh ha finora confermato questo. In definitiva, comunque, solo il tempo ci dirà quando la prima seria vulnerabilità di sicurezza sarà scoperta in Mosh – o perché è sempre stata lì o perché è stata aggiunta inavvertitamente durante lo sviluppo. OpenSSH e OpenSSL hanno avuto più vulnerabilità, ma sono anche stati rilasciati più a lungo e sono più diffusi.

In un aspetto concreto, il protocollo Mosh è più sicuro di quello di SSH: SSH si basa sul TCP non autenticato per trasportare il contenuto del flusso sicuro. Ciò significa che un attaccante può terminare una connessione SSH con un singolo falso segmento “RST”. Al contrario, Mosh applica la sua sicurezza ad un livello diverso (autenticando ogni datagramma), quindi un attaccante non può terminare una sessione Mosh a meno che non possa continuamente impedire ai pacchetti di raggiungere l’altro lato. Un attaccante transitorio può causare solo un’interruzione transitoria visibile all’utente; una volta che l’attaccante se ne va, Mosh riprenderà la sessione.

Tuttavia, nell’uso tipico, Mosh si basa su SSH per scambiare le chiavi all’inizio di una sessione, quindi Mosh erediterà le debolezze di SSH-almeno nella misura in cui esse riguardano la breve sessione SSH che viene usata per impostare una sessione Mosh di lunga durata.

D: Mosh è affetto dagli attacchi del 2018 contro il modo cifrato OCB2?

Non che noi sappiamo: Mosh usa OCB3. Gli autori del paper scrivono che l’attacco non è applicabile a OCB3.

Q: Perché Mosh usa AES-128 per una session-key, e non AES-192 o AES-256?

  • AES-128 è una lunghezza di chiave più che adeguata per una chiave di sessione.
  • Le FAQ di OCB raccomandano AES-128.
  • AES-128 è un po’ più carino e non è soggetto agli attacchi alle chiavi correlate che affliggono AES-192 e AES-256. (Schneier: “il programma della chiave per la versione a 256 bit è abbastanza schifoso — qualcosa che abbiamo sottolineato nel nostro documento del 2000 — ma non si estende ad AES con una chiave a 128 bit”. Vedi questo post sul blog.)

D: Mosh funziona con Amazon EC2?

Sì, funziona benissimo, ma ricordati di aprire le porte UDP 60000-61000 sul firewall EC2.

D: Come faccio a sapere se mosh funziona correttamente?

Dopo aver eseguito mosh user@server, se l’operazione ha avuto successo verrai portato nella tua shell di login sulla macchina remota. Se vuoi controllare che mosh sia usato al posto di ssh, prova a digitare Ctrl-^ Ctrl-Z per sospendere la sessione (con mosh 1.2.4 o successivo sul client). L’esecuzione di fg restituirà poi.

D: Qual è la differenza tra mosh, mosh-client e mosh-server? Quale devo usare?

Il comando mosh è uno script wrapper che è progettato per essere il modo principale con cui usi mosh. Nella maggior parte dei casi, puoi semplicemente sostituire “ssh” con “mosh” nella tua linea di comando. Dietro le quinte, lo script wrapper mosh farà SSH al server, avvierà mosh-server, e poi chiuderà la connessione SSH. Poi avvierà l’eseguibile mosh-client sul client, passandogli le informazioni necessarie per connettersi all’istanza mosh-server appena creata.

Nell’uso normale, mosh-client e mosh-server non hanno bisogno di essere eseguiti direttamente.

D: Come posso eseguire il client e il server mosh separatamente?

Se lo script wrapper mosh non funziona per te, puoi provare ad eseguire i programmi mosh-client e mosh-server separatamente per formare una connessione. Questa può essere un’utile tecnica di debug.

1. Accedi all’host remoto ed esegui mosh-server.

Darà un output come:

$ mosh-server MOSH CONNECT 60004 4NeCCgvZFe2RnPgrcU1PQwmosh-server (mosh 1.1.3)Copyright 2012 Keith Winstein <[email protected]>License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>.This is free software: you are free to change and redistribute it.There is NO WARRANTY, to the extent permitted by law.

2. Sull’host locale, eseguite:

$ MOSH_KEY=key mosh-client remote-IP remote-PORT

dove “key” è la stringa di 22 byte stampata da mosh-server (in questo esempio, “4NeCCgvZFe2RnPgrcU1PQw”), “remote-PORT” è il numero di porta dato dal server (60004 in questo caso), e “remote-IP” è l’indirizzo IP del server. Puoi cercare l’indirizzo IP del server con “host remotehost”.

3. Se tutto va bene, dovresti avere una connessione Mosh funzionante. Le informazioni su dove il processo fallisce possono aiutarci a capire perché Mosh non funziona per te.

D: Con il mosh-server su FreeBSD o OS X, a volte ho strani problemi di colore. Cosa c’è che non va?

Questo bug è stato risolto in Mosh 1.2. Grazie a Ed Schouten e Peter Jeremy per averlo rintracciato.

D: Come posso contribuire a mosh?

Siamo lieti del tuo contributo! Unisciti a noi nel canale #mosh su Freenode IRC, visitaci su GitHub, o invia un’email a [email protected]. Per contribuire al nostro codice base, fai un fork del repository su GitHub e apri una richiesta di pull lì.

D: Chi ha aiutato con mosh?

Siamo molto grati per l’assistenza e il supporto di:

  • Hari Balakrishnan, che ha consigliato questo lavoro e ha inventato il nome.
  • Paul Williams, il cui diagramma di stato vt500 modificato al contrario è la base del parser Mosh.
  • Gli utenti anonimi che hanno contribuito con i log di sessione per mettere a punto e misurare l’eco predittiva di Mosh.
  • Nickolai Zeldovich per utili commenti sul documento di ricerca di Mosh.
  • Richard Stallman per utili discussioni sulle capacità del protocollo di editing locale SUPDUP.
  • Nelson Elhage
  • Christine Spang
  • Stefie Tellex
  • Joseph Sokol-Margolis
  • Waseem Daher
  • Bill McCloskey
  • Austin Roach
  • Greg Hudson
  • Karl Ramm
  • Alexander Chernyakhovsky
  • Peter Iannucci
  • Evan Broder
  • Neha Narula
  • Katrina LaCurts
  • Ramesh Chandra
  • Peter Jeremy
  • Ed Schouten
  • Ryan Steinmetz
  • Jay Freeman
  • Dave Täht
  • Larry Doolittle
  • Daniel Drown
  • Timo Juhani Lindfors
  • Timo Sirainen
  • Ira Cooper
  • Felix Gröbert
  • Luke Mewburn
  • Anton Lundin
  • Philipp Haselwarter
  • Timo J. Rinne
  • Barosl Lee
  • Andrew Chin
  • Louis Kruger
  • Jérémie Courrèges-Anglas
  • Pasi Sjöholm
  • Richard Woodbury
  • Igor Bukanov
  • Geoffrey Thomas
  • Steve Dignam
  • HIGUCHI Yuta
  • Baruch Siach

Lascia un commento

Il tuo indirizzo email non sarà pubblicato.