Mosh

Q: Kuka kirjoitti Moshin?

Moshin kirjoitti Keith Winstein yhdessä Anders Kaseorgin, Quentin Smithin, Richard Tibbettsin, Keegan McAllisterin ja John Hoodin kanssa.

K: Miksi toinen etäpäätteinen protokolla?

Käytännöllinen viive Internetissä on lisääntymässä, kun puskurivyöry ja kehittyneet langattomat linkit, jotka optimoivat läpäisykyvyn viiveen sijaan, ovat yleistyneet. Lisäksi verkkovierailut ovat yleisempiä kuin koskaan, nyt kun kannettavat tietokoneet ja kämmenlaitteet ovat suurelta osin syrjäyttäneet pöytätietokoneet. SSH on hieno, mutta turhauttava käyttää, kun haluat vaihtaa IP-osoitteita tai kun sinulla on pitkä viiveinen linkki tai epävarma yhteys.

TELNETillä oli lisäksi joitakin hyviä puolia – paikallinen kaiku-tila ja hyvin määritelty virtuaalinen verkkopääte. SSH ei edes nykyään tue kunnolla UTF-8:aa päästä päähän POSIX-järjestelmässä.

K: Ovatko mosh-periaatteet relevantteja muissa verkkosovelluksissa?

Meistä kyllä. Suunnitteluperiaatteet, joita Mosh edustaa, ovat konservatiivisia: varoitetaan käyttäjää, jos näytettävä tila on vanhentunut, sarjallistetaan ja tarkistetaan kaikki tapahtumat niin, että jos varoituksia ei tule, käyttäjä tietää, että jokainen aiempi tapahtuma on onnistunut, ja käsitellään odotetut tapahtumat (kuten verkkovierailu WiFi-verkosta toiseen) tyylikkäästi.

Nämä eivät tunnu kovin kiistanalaisilta, mutta hienot sovellukset, kuten Gmail-in-Chromiumissa tai Androidissa, käyttäytyvät edelleen kauhean huonosti epäilyttävillä yhteyksillä tai vaihdettuaan IP-osoitetta. (Oletko koskaan saanut Gmailin jättämään sähköpostiviestin ”Lähetys…” -tilaan kymmeneksi tunniksi samalla kun se hakee iloisesti uutta postia eikä ilmoita minkäänlaista virhettä? Meille myös.) Uskomme, että monissa verkon käyttöliittymissä voi olla huomattavaa parantamisen varaa näiden arvojen soveltamisesta.

K: Saan ilmoituksen ”mosh requires a UTF-8 locale”. Miten voin korjata tämän?

Diagnosoidaksesi ongelman, suorita locale paikallisessa päätelaitteessa ja ssh remotehost locale. Moshin käyttäminen edellyttää, että yhteyden molemmilla puolilla näkyy UTF-8-lokaali, kuten LC_CTYPE="en_US.UTF-8".

Monissa järjestelmissä SSH siirtää paikallisuuteen liittyvät ympäristömuuttujat, jotka periytyvät mosh-server:llä. Jos tämä mekanismi epäonnistuu, Mosh (versiosta 1.2 alkaen) siirtää muuttujat itse. Jos kumpikaan mekanismi ei onnistu, voit tehdä jotain seuraavanlaista:

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

Jos en_US.UTF-8 ei ole olemassa etäpalvelimella, voit korvata sen UTF-8-lokaalilla, joka on olemassa. Sinun on ehkä myös asetettava LANG paikallisesti mosh-client:n eduksi. On mahdollista, että paikallinen ja etäkone tarvitsevat eri lokaalinimiä. Katso myös tämä GitHub-tiketti.

Kysymys: Mitä tarkoittaa viesti ”Palvelimelta ei saatu mitään UDP-porttiin 60003”?

Tämä tarkoittaa, että mosh pystyi käynnistämään mosh-server onnistuneesti etäkoneessa, mutta asiakas ei pysty kommunikoimaan palvelimen kanssa. Tämä tarkoittaa yleensä sitä, että jokin palomuuri estää UDP-paketit asiakkaan ja palvelimen välillä. Jos jouduit välittämään TCP-portin 22 NAT:ssa SSH:ta varten, sinun on välitettävä myös UDP-portit. Mosh käyttää ensimmäistä käytettävissä olevaa UDP-porttia, joka alkaa numerosta 60001 ja päättyy numeroon 60999. Jos palvelimella on vain kourallinen samanaikaisia istuntoja, voit välittää pienemmän määrän portteja (esim. 60000-60010).

Työkalut, kuten netstat, netcat, socat ja tcpdump, voivat olla hyödyllisiä verkko- ja palomuuriongelmien selvittämisessä.

Tämä ongelma voi johtua myös glibc 2.22:ssa olevasta virheestä, joka vaikuttaa ohjelmiin, jotka linkittävät protobufin ja utempterin kanssa ja käyttävät aggressiivisia kääntäjän koventamislippuja. (glibc bugtracker-merkintä, sekä Mosh bugtracker-merkintä.) Ongelma aiheuttaa mosh-serverille segfaultin heti käynnistyksen yhteydessä. Uskomme, että olemme kiertäneet tämän ongelman Mosh 1.2.6:ssa, mutta ilmoita virheestä, jos huomaat toisin.

Q: Miksi vaaditte UTF-8:a kaikkialla?

Me emme todellakaan ole UTF-8-fanaatikkoja. Mutta on paljon helpompaa toteuttaa yksi pääte-emulaattori oikein kuin yrittää tehdä oikein monissa vaikeissa ääritapauksissa. (Tätä GNU screen yrittää tehdä, ja kokemuksemme mukaan se johtaa hyvin hankaliin virheenkorjaustilanteisiin.) Joten mosh ei vain käynnisty ennen kuin käyttäjä on konfiguroinut kaiken UTF-8-puhdasta polkua varten. Se voi olla ärsyttävää, mutta se luultavasti myös vähentää turhautumista myöhemmin. (Valitettavasti 8-bittinen vt220 ja UTF-8 vt220 ovat erilaisia ja yhteensopimattomia päätelaitetyyppejä; UTF-8 menee vt220:n tilakoneen alle.)

K: Miten käytän eri SSH-porttia (ei 22)?

Mosh 1.2:sta lähtien voit välittää argumentteja ssh:lle näin:

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

Tai konfiguroida hostin alias ~/.ssh/config:ssa Port-direktiivillä. Mosh kunnioittaa myös sitä.

K: Saan ilmoituksen ’mosh-server not found’.

Varmista, että mosh on asennettu asiakkaalle ja mosh (tai ainakin mosh-server) on asennettu palvelimelle, johon yrität muodostaa yhteyden. Lisäksi palvelimen odotetaan olevan käytettävissä palvelimen oletuskirjautumistunnuksella PATH, mikä ei yleensä pidä paikkaansa OS X- ja BSD-palvelimilla tai jos asennat mosh-serverin kotihakemistoosi. Näissä tapauksissa katso ”Palvelimen binääritiedosto polun ulkopuolella” -ohjeet yllä olevassa Käyttö-osiossa.

K: SSH todennetaan käyttämällä Kerberos-lippuja, mutta Mosh kysyy minulta salasanaa.

Joissain kokoonpanoissa SSH kanonisoi isäntänimen ennen sen välittämistä Kerberos GSSAPI -lisäosalle. Tämä häiritsee Moshia, koska Moshin wrapper-skripti tekee alkuperäisen eteenpäin suuntautuvan DNS-haun. Voit kiertää tämän kutsumalla Moshia as

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

Tämä epäonnistuu usein round-robin DNS-asetuksissa. Siinä tapauksessa on luultavasti parasta valita tietty isäntä round-robin-poolista.

K: Miksi terminaalini selauspuskuri on epätäydellinen?

Mosh synkronoi vain päätelaitteen näkyvän tilan. Seuraamme tätä ongelmaa; katso tämä ongelma ja muut, jotka on linkitetty sieltä. Toistaiseksi kiertotie on käyttää screeniä tai tmuxia etäpuolella.

K: Miten saan 256 väriä?

Varmista, että käytät moshia päätelaitteessa, joka mainostaa olevansa 256-värinen. (Tämä tarkoittaa yleensä, että TERM on xterm-256color tai screen-256color-bce.)

K: Miten kirjoitan C-^, moshin oletusarvoisen pakomerkin?

Näppäimistöissä, joissa on yhdysvaltalainen asettelu, tämä voidaan kirjoittaa muodossa Ctrl-Shift-6 tai usein Ctrl-6 (tämä riippuu käyttöjärjestelmästäsi ja terminaali-emulaattoristasi). Muilla kuin yhdysvaltalaisilla näppäimistöillä oikean näppäimen löytäminen on usein vaikeaa, ja joskus sitä ei ole lainkaan saatavilla. Jos näppäimistössäsi on kuollut näppäin, jossa on aksentti-circumflex, se ei todennäköisesti ole oikea näppäin. Ctrl-6 toimii kuitenkin joskus. Jos et pysty kirjoittamaan tätä merkkiä, sinun on asetettava muuttuja MOSH_ESCAPE_KEY; katso lisätietoja Mosh man-sivulta.

K: Miten saan palvelimen siivoamaan lepotilassa olevat istunnot automaattisesti?

Katso merkinnät MOSH_SERVER_NETWORK_TMOUT ja MOSH_SERVER_SIGNAL_TMOUT mosh-server(1) man-sivulta.

K: Mikä on Moshin tietoturvatilanne tähän mennessä?

Mosh 1.0 julkaistiin maaliskuussa 2012. Mosh 1.3.2:n julkaisusta heinäkuussa 2017 lähtien kehittäjien tietojen mukaan:

• Viimeisten neljän vuoden aikana Moshissa ei ole raportoitu minkäänlaisia tietoturva-aukkoja (suuria tai pieniä).
• Moshissa ei ole koskaan raportoitu merkittäviä tietoturva-aukkoja. Määrittelemme suuriksi tietoturvaheikkouksiksi etuoikeuksien laajentamisen, etäkoodin suorittamisen, kolmannen osapuolen suorittaman palveluneston jne.
• Kaksi palvelunesto-ongelmaa löydettiin ja korjattiin vuoden 2012 versioissa. Toisen ongelman avulla mosh-palvelin saattoi aiheuttaa sen, että mosh-client käytti liikaa prosessoria (CVE-2012-2385, korjattu Mosh1.2.1:ssä, julkaistu toukokuussa 2012). Toinen ongelma aiheutti sen, että palvelinhost sai mosh-asiakkaan lähettämään UDP-datagrammeja väärään osoitteeseen, mikä esti sen yhteydenmuodostusyrityksen (korjattu Mosh 1.2.3:ssa, julkaistu lokakuussa 2012).

K: Miten Moshin tietoturva vertautuu SSH:n tietoturvaan?

Meistä Moshin konservatiivinen suunnittelu tarkoittaa, että sen hyökkäyspinta vertautuu edullisesti monimutkaisempiin järjestelmiin, kuten OpenSSL:ään ja OpenSSH:hen. Moshin saavutukset ovat toistaiseksi osoittaneet tämän. Viime kädessä kuitenkin vain aika näyttää, milloin Moshista löydetään ensimmäinen vakava tietoturva-aukko – joko siksi, että se oli siellä koko ajan, tai siksi, että se lisättiin epähuomiossa kehitystyön aikana. OpenSSH:ssa ja OpenSSL:ssä on ollut enemmän haavoittuvuuksia, mutta niitä on myös julkaistu pidempään ja ne ovat yleisempiä.

Yhdessä konkreettisessa suhteessa Mosh-protokolla on turvallisempi kuin SSH:n: SSH luottaa varmentamattoman TCP:n välittämään suojatun virran sisällön. Tämä tarkoittaa, että hyökkääjä voi lopettaa SSH-yhteyden yhdellä väärennetyllä ”RST”-segmentillä. Sitä vastoin Mosh käyttää tietoturvaa eri kerroksessa (todentamalla jokaisen datagrammin), joten hyökkääjä ei voi lopettaa Mosh-istuntoa, ellei hyökkääjä pysty jatkuvasti estämään pakettien saapumista toiselle puolelle. Ohimenevä hyökkääjä voi aiheuttaa vain ohimenevän, käyttäjälle näkyvän katkoksen; kun hyökkääjä poistuu, Mosh jatkaa istuntoa.

Tyypillisessä käytössä Mosh kuitenkin luottaa SSH:n avainten vaihtoon istunnon alussa, joten Mosh perii SSH:n heikkoudet – ainakin siltä osin kuin ne vaikuttavat lyhyeen SSH-istuntoon, jota käytetään pitkäkestoisen Mosh-istunnon perustamiseen.

K: Vaikuttavatko vuoden 2018 hyökkäykset OCB2-salausmoodia vastaan Moshiin?

Eivät tietojemme mukaan – Mosh käyttää OCB3:aa. Paperin kirjoittajat kirjoittavat, että hyökkäys ei sovellu OCB3:een.

K: Miksi mosh käyttää istuntoavaimena AES-128:a eikä AES-192:ta tai AES-256:ta?

• AES-128 on enemmän kuin riittävä avaimen pituus istuntoavaimeksi.
• OCB FAQ suosittelee AES-128:aa.
• AES-128 on hieman mukavampi eikä siihen kohdistu AES-192:ta ja AES-256:ta vaivaavia sukulaisavainhyökkäyksiä. (Schneier: ”256-bittisen version avaimiaikataulu on melko surkea – jotain, mistä huomautimme vuonna 2000 julkaistussa artikkelissamme – mutta se ei ulotu 128-bittisellä avaimella varustettuun AES:ään.”” Katso tämä blogikirjoitus.)

K: Toimiiko mosh Amazon EC2:n kanssa?

Kyllä, se toimii loistavasti, mutta muista avata UDP-portit 60000-61000 EC2:n palomuurissa.

K: Mistä tiedän, toimiiko mosh oikein?

Kun suoritat mosh user@server, jos se onnistuu, pääset kirjautumissuorittimeen etäkoneella. Jos haluat tarkistaa, että moshia käytetään ssh:n sijasta, kokeile keskeyttää istunto kirjoittamalla Ctrl-^ Ctrl-Z (mosh 1.2.4:llä tai uudemmalla clientillä). Suorittamalla fg palaat sitten takaisin.

K: Mitä eroa on mosh:lla, mosh-clientillä ja mosh-serverillä? Mitä niistä käytän?

Komento mosh on wrapper-skripti, joka on suunniteltu ensisijaiseksi tavaksi käyttää moshia. Useimmissa tapauksissa voit yksinkertaisesti korvata komentorivilläsi ”ssh” sanalla ”mosh”. Kulissien takana mosh wrapper-skripti tekee SSH-yhteyden palvelimelle, käynnistää mosh-server ja sulkee SSH-yhteyden. Sitten se käynnistää mosh-client:n suoritettavan ohjelman asiakkaalla ja välittää sille tarvittavat tiedot, jotta se voi muodostaa yhteyden äskettäin luotuun mosh-server-instanssiin.

Normaalikäytössä mosh-client ja mosh-server ei tarvitse ajaa suoraan.

K: Miten mosh-asiakas ja palvelin ajetaan erikseen?

Jos mosh wrapper-skripti ei toimi sinulle, voit kokeilla ajaa mosh-client– ja mosh-server-ohjelmat erikseen yhteyden muodostamiseksi. Tämä voi olla hyödyllinen virheenkorjaustekniikka.

1. Kirjaudu sisään etä-isäntäkoneeseen ja suorita mosh-server.

Se antaa tulosteen kuten:

$ 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. Suorita paikallisessa isännässä:

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

jossa ”key” on mosh-palvelimen tulostama 22 tavun merkkijono (tässä esimerkissä ”4NeCCgvZFe2RnPgrcU1PQw”), ”remote-PORT” on palvelimen antama porttinumero (tässä tapauksessa 60004) ja ”remote-IP” on palvelimen IP-osoite. Voit etsiä palvelimen IP-osoitteen komennolla ”host remotehost”.

3. Jos kaikki menee hyvin, sinulla pitäisi olla toimiva Mosh-yhteys. Tieto siitä, missä kohtaa prosessi epäonnistuu, voi auttaa meitä selvittämään, miksi Mosh ei toimi sinulle.

K: Kun mosh-palvelin on FreeBSD:ssä tai OS X:ssä, saan joskus outoja väriongelmia. Mikä on vialla?

Tämä vika on korjattu Mosh 1.2:ssa. Kiitos Ed Schoutenille ja Peter Jeremylle tämän jäljittämisestä.

K: Miten voin osallistua moshiin?

Olemme tervetulleita osallistumaan! Liity meihin #mosh-kanavalla Freenode IRC:ssä, käy GitHubissa tai lähetä sähköpostia [email protected]. Jos haluat vaikuttaa koodipohjaamme, haarukoi arkisto GitHubissa ja avaa pull request siellä.

K: Kuka auttoi mosh:n kehittämisessä?

Olemme hyvin kiitollisia avusta ja tuesta:

• Hari Balakrishnanilta, joka neuvoi tässä työssä ja keksi nimen.
• Paul Williamsilta, jonka käänteisesti muokattu vt500:n tilakaavio on Moshin jäsentimen perusta.
• Anonyymit käyttäjät, jotka antoivat istuntolokeja Moshin ennakoivan kaiun virittämistä ja mittaamista varten.
• Nickolai Zeldovich hyödyllisistä kommenteista Mosh-tutkimuspaperiin.
• Richard Stallman hyödyllisestä keskustelusta, joka koski SUPDUP-paikallismuokkausprotokollan ominaisuuksia.
• 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