Mosh

Întrebare: Cine a scris Mosh?

Mosh a fost scris de Keith Winstein, împreună cu Anders Kaseorg, Quentin Smith, Richard Tibbetts, Keegan McAllister și John Hood.

Î: De ce un alt protocol de terminal la distanță?

Latența practică pe internet este în creștere, odată cu apariția bufferbloat-ului și a legăturilor wireless sofisticate care optimizează debitul față de întârziere. Iar roaming-ul este mai comun ca niciodată, acum că laptopurile și dispozitivele portabile au înlocuit în mare parte desktopurile. SSH este grozav, dar este frustrant de utilizat atunci când doriți să schimbați adresele IP sau când aveți o legătură cu întârziere mare sau o conexiune dubioasă.

În plus, TELNET a avut câteva lucruri bune în favoarea sa – un mod local-eco și un terminal virtual de rețea bine definit. Chiar și astăzi, SSH nu suportă în mod corespunzător UTF-8 end-to-end pe un sistem POSIX.

Î: Sunt principiile mosh relevante pentru alte aplicații de rețea?

Credem că da. Principiile de proiectare pe care Mosh le susține sunt conservatoare: avertizarea utilizatorului dacă starea afișată este depășită, serializarea și verificarea tuturor tranzacțiilor, astfel încât, dacă nu există avertismente, utilizatorul știe că fiecare tranzacție anterioară a reușit și gestionarea evenimentelor așteptate (cum ar fi roaming-ul de la o rețea WiFi la alta) în mod grațios.

Acestea nu par prea controversate, dar aplicațiile sofisticate, cum ar fi Gmail-in-Chromium sau pe Android, încă se comportă atroce pe conexiuni dubioase sau după schimbarea adreselor IP. (Ți s-a întâmplat vreodată ca Gmail să lase un mesaj de e-mail în „Trimitere…” timp de zece ore, în timp ce prelua cu voioșie mesaje noi și nu indica niciun fel de eroare? Și noi la fel). Credem că ar putea exista o marjă considerabilă de îmbunătățire în multe interfețe utilizator de rețea din aplicarea acestor valori.

Î: Primesc „mosh requires a UTF-8 locale”. Cum pot rezolva acest lucru?

Pentru a diagnostica problema, rulați locale pe terminalul local, și ssh remotehost locale. Pentru a utiliza Mosh, ambele părți ale conexiunii vor trebui să afișeze un locale UTF-8, cum ar fi LC_CTYPE="en_US.UTF-8".

Pe multe sisteme, SSH va transfera variabilele de mediu legate de locale, care sunt apoi moștenite de mosh-server. Dacă acest mecanism eșuează, Mosh (începând cu versiunea 1.2) va transmite el însuși variabilele. Dacă niciunul dintre cele două mecanisme nu are succes, puteți face ceva de genul

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

Dacă en_US.UTF-8 nu există pe serverul de la distanță, puteți înlocui acest lucru cu un locale UTF-8 care există. De asemenea, este posibil să fie necesar să setați LANG la nivel local pentru a beneficia de mosh-client. Este posibil ca mașinile locale și cele de la distanță să aibă nevoie de nume locale diferite. Consultați, de asemenea, acest bilet GitHub.

Î: Ce înseamnă mesajul „Nimic primit de la server pe portul UDP 60003”?

Aceasta înseamnă că mosh a reușit să pornească mosh-server cu succes pe mașina la distanță, dar clientul nu poate comunica cu serverul. Acest lucru înseamnă, în general, că un anumit tip de firewall blochează pachetele UDP între client și server. Dacă a trebuit să redirecționați portul TCP 22 pe un NAT pentru SSH, atunci va trebui să redirecționați și porturile UDP. Mosh va utiliza primul port UDP disponibil, începând cu 60001 și oprindu-se la 60999. Dacă veți avea doar o mână mică de sesiuni simultane pe un server, atunci puteți redirecționa un interval mai mic de porturi (de exemplu, de la 60000 la 60010).

Instrumente precum netstat, netcat, socat și tcpdump pot fi utile pentru depanarea problemelor de rețea și de firewall.

Această problemă poate fi, de asemenea, rezultatul unei erori din glibc 2.22 care afectează programele care se leagă cu protobuf și utempter și care utilizează stegulețe agresive de întărire a compilatorului. (intrarea în bugtracker-ul glibc, precum și intrarea în bugtracker-ul Mosh.) Problema face ca mosh-server să facă segfault imediat la pornire. Credem că am rezolvat această problemă în Mosh 1.2.6, dar vă rugăm să raportați un bug dacă descoperiți altceva.

Î: De ce insistați pe UTF-8 peste tot?

Noi chiar nu suntem zeloși UTF-8. Dar este mult mai ușor să implementăm corect un emulator de terminal decât să încercăm să facem ceea ce trebuie într-o varietate de cazuri limită dificile. (Aceasta este ceea ce încearcă să facă GNU screen și, din experiența noastră, duce la unele situații foarte dificile de depanat). Așadar, mosh pur și simplu nu va porni până când utilizatorul nu are totul configurat pentru o cale UTF-8-clean. Poate fi enervant, dar, de asemenea, probabil că reduce frustrările pe parcurs. (Din nefericire, un vt220 pe 8 biți și un vt220 UTF-8 sunt tipuri de terminale diferite și incompatibile; UTF-8 intră sub mașina de stare vt220.)

Î: Cum pot folosi un port SSH diferit (nu 22)?

De la Mosh 1.2, puteți trece argumente către ssh astfel:

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

Ou configurați un alias de gazdă în ~/.ssh/config cu o directivă Port. Mosh o va respecta și pe aceasta.

Î: Primesc ‘mosh-server not found’.

Vă rog să vă asigurați că mosh este instalat pe client și că mosh (sau cel puțin mosh-server) este instalat pe serverul la care încercați să vă conectați. De asemenea, se așteaptă ca serverul să fie disponibil pe login-ul implicit al serverului PATH, ceea ce nu este de obicei adevărat pe serverele OS X și BSD, sau dacă instalați mosh-server în directorul dvs. personal. În aceste cazuri, vă rugăm să consultați instrucțiunile „Server binary outside path” din secțiunea Usage, de mai sus.

Î: SSH se autentifică folosind bilete Kerberos, dar Mosh îmi cere o parolă.

În unele configurații, SSH canonicalizează numele de gazdă înainte de a-l transmite plugin-ului Kerberos GSSAPI. Acest lucru se întrerupe pentru Mosh, deoarece căutarea inițială a DNS-ului înainte este realizată de scriptul de înfășurare Mosh. Pentru a rezolva această problemă, invocați Mosh as

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

Acest lucru va eșua adesea într-o configurație DNS round-robin. În acest caz, este probabil cel mai bine să alegeți o anumită gazdă din pool-ul round-robin.

Î: De ce este incomplet bufferul de derulare înapoi al terminalului meu?

Mosh sincronizează numai starea vizibilă a terminalului. Urmărim această problemă; consultați această problemă și celelalte care sunt legate de ea. Deocamdată, soluția de lucru este să folosiți screen sau tmux pe partea de la distanță.

Î: Cum obțin 256 de culori?

Asigurați-vă că rulați mosh într-un terminal care se anunță a fi capabil de 256 de culori. (Aceasta înseamnă, în general, că TERM va fi xterm-256color sau screen-256color-bce.)

Î: Cum tastez C-^, caracterul de scăpare implicit al lui Mosh?

Pe tastaturile cu layout din Statele Unite, acesta poate fi tastat ca Ctrl-Shift-6, sau adesea ca Ctrl-6 (acest lucru depinde de sistemul de operare și de emulatorul de terminal). Pe tastaturile din afara Statelor Unite, este adesea greu de găsit tasta corectă și, uneori, nu este disponibilă deloc. Dacă tastatura dvs. are o tastă moartă cu un accent-circumflex, este puțin probabil ca aceasta să fie tasta corectă. Totuși, Ctrl-6 funcționează uneori. Dacă nu puteți tasta acest caracter, va trebui să setați variabila MOSH_ESCAPE_KEY; consultați pagina de manual Mosh pentru detalii.

Î: Cum pot face ca serverul să curețe automat sesiunile inactive?

Vă rugăm să consultați intrările pentru MOSH_SERVER_NETWORK_TMOUT și MOSH_SERVER_SIGNAL_TMOUT din pagina de manual mosh-server(1).

Î: Care este palmaresul de securitate al lui Mosh până în prezent?

Mosh 1.0 a fost lansat în martie 2012. Începând cu lansarea lui Mosh 1.3.2 în iulie 2017, din câte știu dezvoltatorii:

• În ultimii patru ani, nu au fost raportate vulnerabilități de securitate de niciun fel (majore sau minore) în Mosh.
• Nu au fost raportate niciodată vulnerabilități majore de securitate în Mosh. Noi definim vulnerabilitățile majore de securitate pentru a include escaladarea privilegiilor, executarea de cod de la distanță, refuzul de serviciu de către o terță parte etc.
• Două probleme de negare a serviciului au fost descoperite și remediate în versiunile din 2012. O problemă a permis unui mosh-server să facă ca mosh-client să cheltuiască un exces de CPU (CVE-2012-2385, corectat în Mosh1.2.1, lansat în mai 2012). O altă problemă a permis serverului-gazdă să determine mosh-client să trimită datagrame UDP la o adresă incorectă, zădărnicindu-i încercarea de conectare (corectată înMosh 1.2.3, lansat în octombrie 2012).

Î: Cum se compară securitatea lui Mosh cu cea a lui SSH?

Credeam că designul conservator al lui Mosh înseamnă că suprafața sa de atac se compară favorabil cu sisteme mai complicate precum OpenSSL și OpenSSH. Până în prezent, istoricul lui Mosh a confirmat acest lucru. Cu toate acestea, în cele din urmă, doar timpul ne va spune când va fi descoperită prima vulnerabilitate gravă de securitate în Mosh – fie pentru că a fost acolo de la început, fie pentru că a fost adăugată din greșeală în timpul dezvoltării. OpenSSH și OpenSSL au avut mai multe vulnerabilități, dar, de asemenea, au fost lansate de mai mult timp și sunt mai răspândite.

Într-o privință concretă, protocolul Mosh este mai sigur decât cel al SSH: SSH se bazează pe TCP neautentificat pentru a transporta conținutul fluxului securizat. Aceasta înseamnă că un atacator poate încheia o conexiune SSH cu un singur segment „RST” fals. În schimb, Mosh își aplică securitatea la un nivel diferit (autentificând fiecare datagramă), astfel încât un atacator nu poate încheia o sesiune Mosh decât dacă poate împiedica în mod continuu pachetele să ajungă de cealaltă parte. Un atacator tranzitoriu poate provoca doar o întrerupere tranzitorie vizibilă pentru utilizator; odată ce atacatorul dispare, Mosh va relua sesiunea.

Cu toate acestea, în utilizarea tipică, Mosh se bazează pe SSH pentru a face schimb de chei la începutul unei sesiuni, astfel încât Mosh va moșteni punctele slabe ale SSH – cel puțin în măsura în care acestea afectează scurta sesiune SSH care este utilizată pentru a configura o sesiune Mosh de lungă durată.

Î: Este Mosh afectat de atacurile din 2018 împotriva modului de cifrare OCB2?

Nu din câte știm noi-Mosh folosește OCB3. Autorii lucrării scriu că atacul nu este aplicabil la OCB3.

Î: De ce Mosh folosește AES-128 pentru o cheie de sesiune, și nu AES-192 sau AES-256?

• AES-128 este o lungime de cheie mai mult decât adecvată pentru o cheie de sesiune.
• Pregătirea frecventă OCB recomandă AES-128.
• AES-128 este un pic mai frumos și nu este supus atacurilor cu cheie conexă care afectează AES-192 și AES-256. (Schneier: „programul de chei pentru versiunea pe 256 de biți este destul de prost – lucru pe care l-am subliniat în lucrarea noastră din 2000 – dar nu se extinde la AES cu o cheie pe 128 de biți.” A se vedea această postare pe blog.)

Î: Funcționează mosh cu Amazon EC2?

Da, funcționează foarte bine, dar vă rugăm să nu uitați să deschideți porturile UDP 60000-61000 pe firewall-ul EC2.

Î: Cum îmi dau seama dacă mosh funcționează corect?

După ce executați mosh user@server, dacă are succes, veți fi aruncat în shell-ul de conectare pe mașina la distanță. Dacă doriți să verificați dacă mosh este utilizat în loc de ssh, încercați să tastați Ctrl-^ Ctrl-Z pentru a suspenda sesiunea (cu mosh 1.2.4 sau o versiune ulterioară pe client). Rularea fg va reveni apoi.

Î: Care este diferența dintre mosh, mosh-client și mosh-server? Pe care îl folosesc?

Comanda mosh este un script de înfășurare care este conceput pentru a fi modul principal prin care utilizați mosh. În majoritatea cazurilor, puteți pur și simplu să înlocuiți „ssh” cu „mosh” în linia de comandă. În spatele scenei, scriptul de înfășurare mosh va face SSH la server, va porni mosh-server și apoi va închide conexiunea SSH. Apoi va porni executabilul mosh-client pe client, transmițându-i informațiile necesare pentru ca acesta să se conecteze la instanța mosh-server nou creată.

În utilizarea normală, mosh-client și mosh-server nu trebuie să fie rulate direct.

Î: Cum pot rula clientul și serverul mosh separat?

Dacă scriptul de înfășurare mosh nu funcționează pentru dumneavoastră, puteți încerca să rulați programele mosh-client și mosh-server separat pentru a forma o conexiune. Aceasta poate fi o tehnică utilă de depanare.

1. Conectați-vă la gazda de la distanță și rulați mosh-server.

Se va obține o ieșire de tipul:

$ 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. Pe gazda locală, executați:

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

unde „key” este șirul de 22 de octeți tipărit de mosh-server (în acest exemplu, „4NeCCgvZFe2RnPgrcU1PQw”), „remote-PORT” este numărul de port dat de server (60004 în acest caz), iar „remote-IP” este adresa IP a serverului. Puteți căuta adresa IP a serverului cu „host remotehost”.

3. Dacă totul merge bine, ar trebui să aveți o conexiune Mosh funcțională. Informațiile despre punctele în care procesul eșuează ne pot ajuta să depanăm motivul pentru care Mosh nu funcționează pentru dumneavoastră.

Î: Cu mosh-serverul pe FreeBSD sau OS X, uneori am probleme ciudate cu culorile. Ce s-a întâmplat?

Acest bug este rezolvat în Mosh 1.2. Mulțumiri lui Ed Schouten și Peter Jeremy pentru depistarea acesteia.

Î: Cum pot contribui la mosh?

Sunt binevenite contribuțiile dumneavoastră! Vă rugăm să ni vă alăturați în canalul #mosh pe Freenode IRC, vizitați-ne pe GitHub sau trimiteți un e-mail la [email protected]. Pentru a contribui la baza noastră de cod, vă rugăm să faceți o furculiță la depozitul de pe GitHub și să deschideți o cerere de tragere acolo.

Î: Cine a ajutat la mosh?

Suntem foarte recunoscători pentru asistență și sprijin din partea:

• Hari Balakrishnan, care a sfătuit această lucrare și a venit cu numele.
• Paul Williams, a cărui diagramă de stare vt500 cu inginerie inversă este baza pentru parserul Mosh.
• Utilizatorii anonimi care au contribuit cu jurnale de sesiune pentru reglarea și măsurarea ecoului predictiv al lui Mosh.
• Nickolai Zeldovich pentru comentarii utile asupra lucrării de cercetare Mosh.
• Richard Stallman pentru discuții utile despre capacitățile protocolului de editare locală 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

.