Mosh

K: Ki írta a Mosh-t?

A Mosht Keith Winstein írta, Anders Kaseorggal, Quentin Smith-szel, Richard Tibbetts-szel, Keegan McAllisterrel és John Hooddal együtt.

K: Miért egy másik távoli terminál protokoll?

A gyakorlati késleltetés az interneten egyre nő, a bufferbloat és a kifinomult vezeték nélküli kapcsolatok terjedésével, amelyek a késleltetés helyett az áteresztőképességet optimalizálják. A barangolás pedig gyakoribb, mint valaha, most, hogy a laptopok és a kézi eszközök nagyrészt kiszorították az asztali számítógépeket. Az SSH nagyszerű, de frusztráló a használata, ha IP-címet akarsz változtatni, vagy ha hosszú késleltetésű vagy gyanús kapcsolatod van.

A TELNET-nek volt néhány jó tulajdonsága – a helyi visszhangos mód és egy jól definiált hálózati virtuális terminál. Az SSH még ma sem támogatja megfelelően az UTF-8 végponttól-végpontig tartó UTF-8-at egy POSIX-rendszeren.

K: A mosh-elvek más hálózati alkalmazásokra is vonatkoznak?

Szerintünk igen. A Mosh által képviselt tervezési elvek konzervatívak: figyelmeztetés a felhasználónak, ha a megjelenített állapot elavult, minden tranzakció szerializálása és ellenőrzőpontozása, hogy ha nincs figyelmeztetés, a felhasználó tudja, hogy minden korábbi tranzakció sikeres volt, és a várható események (például az egyik WiFi hálózatról egy másikra való barangolás) méltóságteljes kezelése.

Ezek nem tűnnek túl ellentmondásosnak, de az olyan divatos alkalmazások, mint a Gmail-in-Chromium vagy Androidon még mindig szörnyen viselkednek kétes kapcsolatokon vagy IP-címváltás után. (Volt már olyan, hogy a Gmail tíz órán keresztül “Küldés…” állapotban hagyott egy e-mailt, miközben vidáman lekérte az új leveleket, és nem jelzett semmiféle hibát? Nekünk is.) Úgy gondoljuk, hogy ezeknek az értékeknek az alkalmazásából sok hálózati felhasználói felületen jelentős javulás érhető el.

K: Azt kapom, hogy “mosh requires a UTF-8 locale”. Hogyan tudom ezt kijavítani?

A probléma diagnosztizálásához futtassa a helyi terminálon a locale és a ssh remotehost locale parancsot. A Mosh használatához a kapcsolat mindkét oldalán UTF-8-as nyelvjárásnak kell megjelennie, például LC_CTYPE="en_US.UTF-8".

Sok rendszeren az SSH átadja a nyelvjárással kapcsolatos környezeti változókat, amelyeket aztán a mosh-server örököl. Ha ez a mechanizmus nem működik, a Mosh (az 1.2-es verziótól kezdve) maga adja át a változókat. Ha egyik mechanizmus sem jár sikerrel, akkor valami olyasmit tehetünk, mint

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

Ha a en_US.UTF-8 nem létezik a távoli kiszolgálón, akkor ezt egy létező UTF-8 locale-val helyettesíthetjük. Lehet, hogy a mosh-client előnyére helyileg is be kell állítania a LANG-ot. Elképzelhető, hogy a helyi és a távoli gépeknek eltérő nyelvi nevekre lesz szükségük. Lásd még ezt a GitHub jegyet.

K: Mit jelent a “Semmi nem érkezett a kiszolgálótól a 60003-as UDP porton” üzenet?

Ez azt jelenti, hogy mosh sikeresen el tudta indítani mosh-server a távoli gépen, de a kliens nem tud kommunikálni a kiszolgálóval. Ez általában azt jelenti, hogy valamilyen tűzfal blokkolja az UDP csomagokat az ügyfél és a kiszolgáló között. Ha egy NAT-on a 22-es TCP portot kellett továbbítania az SSH-hoz, akkor az UDP portokat is továbbítania kell. A Mosh az első elérhető UDP-portot fogja használni, a 60001-től a 60999-ig. Ha csak néhány párhuzamos munkamenet lesz egy kiszolgálón, akkor a portok kisebb tartományát is továbbíthatja (pl. 60000-tól 60010-ig).

Az olyan eszközök, mint a netstat, netcat, socat és tcpdump hasznosak lehetnek a hálózati és tűzfalproblémák elhárításában.

Ez a probléma a glibc 2.22-ben található hiba eredménye is lehet, amely a protobuf és az utempter segítségével linkelő és agresszív fordítói keményítő flageket használó programokat érinti. (glibc bugtracker bejegyzés, valamint Mosh bugtracker bejegyzés.) A probléma a mosh-server indításakor azonnal segfaultot okoz. Úgy hisszük, hogy a Mosh 1.2.6-ban megoldottuk ezt a problémát, de kérjük, jelezd a hibát, ha másképp látod.

Q: Miért ragaszkodsz mindenhol az UTF-8-hoz?

Tényleg nem vagyunk UTF-8 fanatikusok. De sokkal könnyebb helyesen implementálni egy terminál emulátort, mint megpróbálni helyesen cselekedni a különböző nehéz szélsőséges esetekben. (Ezt próbálja megtenni a GNU screen, és tapasztalataink szerint ez nagyon trükkös hibakeresési helyzetekhez vezet.) Tehát a mosh egyszerűen nem fog elindulni, amíg a felhasználó nem konfigurál mindent UTF-8-tiszta útvonalra. Ez lehet, hogy bosszantó, de valószínűleg csökkenti a frusztrációt a későbbiekben. (Sajnos egy 8 bites vt220 és egy UTF-8 vt220 különböző és inkompatibilis termináltípusok; az UTF-8 a vt220 állapotgép alá kerül.)

K: Hogyan használhatok más SSH portot (nem 22)?

A Mosh 1.2-től kezdve a ssh-nek átadhatsz argumentumokat a következőképpen:

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

Vagy konfigurálhatsz egy host aliast a ~/.ssh/config-ban egy Port direktívával. A Mosh ezt is tiszteletben fogja tartani.

K: Azt kapom, hogy ‘mosh-server not found’.

Kérlek győződj meg róla, hogy a mosh telepítve van a kliensen, és a mosh (vagy legalább a mosh-server) telepítve van a szerveren, amelyhez csatlakozni próbálsz. Továbbá, a szerver várhatóan elérhető lesz a szerver alapértelmezett bejelentkezési PATH címén, ami általában nem igaz az OS X és BSD szervereken, vagy ha a mosh-server-t a saját home könyvtárába telepíti. Ezekben az esetekben kérjük, olvassa el a fenti Használat szakaszban a “Kiszolgáló bináris elérési útvonalon kívüli” utasításokat.

K: Az SSH Kerberos jegyekkel hitelesíti magát, de a Mosh jelszót kér tőlem.

Egyes konfigurációkban az SSH kanonizálja a hostnevet, mielőtt átadja a Kerberos GSSAPI bővítménynek. Ez a Mosh esetében megszakad, mivel a kezdeti forward DNS-keresést a Mosh wrapper szkript végzi. Ennek kiküszöbölésére hívja meg a Mosh-t as

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

Ez gyakran nem fog sikerülni egy körkörös DNS-beállításnál. Ebben az esetben valószínűleg az a legjobb, ha a round-robin poolból választunk egy adott hostot.

K: Miért nem teljes a terminálom scrollback pufferje?

A Mosh csak a terminál látható állapotát szinkronizálja. Ezt a problémát nyomon követjük; lásd ezt a problémát és az onnan linkelt többi problémát. Egyelőre a megoldás a screen vagy a tmux használata a távoli oldalon.

K: Hogyan kapok 256 színt?

Győződj meg róla, hogy a mosh-t olyan terminálon futtatod, amely 256 színűnek hirdeti magát. (Ez általában azt jelenti, hogy a TERM xterm-256color vagy screen-256color-bce lesz.)

K: Hogyan írom be a C-^-t, a Mosh alapértelmezett escape karakterét?

Az Egyesült Államokban használt billentyűzeteken ez Ctrl-Shift-6, vagy gyakran Ctrl-6 (ez az operációs rendszertől és a terminálemulátortól függ). A nem amerikai billentyűzeteken gyakran nehéz megtalálni a megfelelő billentyűt, és néha egyáltalán nem is elérhető. Ha a billentyűzetén van egy halott billentyű ékezetes-cirkumflexszel, akkor valószínűleg nem ez a megfelelő billentyű. A Ctrl-6 azonban néha működik. Ha nem tudod beírni ezt a karaktert, akkor be kell állítanod a MOSH_ESCAPE_KEY változót; a részletekért lásd a Mosh man oldalát.

K: Hogyan tudom elérni, hogy a szerver automatikusan megtisztítsa a szunnyadó munkameneteket?

Lásd a mosh-server(1) man oldal MOSH_SERVER_NETWORK_TMOUT és MOSH_SERVER_SIGNAL_TMOUT bejegyzéseit.

K: Milyen a Mosh eddigi biztonsági teljesítménye?

A Mosh 1.0 2012 márciusában jelent meg. A Mosh 1.3.2 2017. júliusi kiadásától kezdve a fejlesztők tudomása szerint:

• Az elmúlt négy évben semmilyen (kisebb vagy nagyobb) biztonsági rést nem jelentettek a Mosh-ban.
• A Mosh-ban soha nem jelentettek nagyobb biztonsági rést. A súlyos biztonsági réseket úgy definiáljuk, mint jogosultságok kiterjesztése, távoli kódfuttatás, harmadik fél általi szolgáltatásmegtagadás stb.
• Két szolgáltatásmegtagadási problémát fedeztek fel és javítottak a 2012-es kiadásokban. Az egyik probléma lehetővé tette, hogy a mosh-kiszolgáló a mosh-kliens számára többlet CPU-felhasználást idézzen elő (CVE-2012-2385, javítva a 2012 májusában megjelent Mosh1.2.1 verzióban). Egy másik probléma lehetővé tette, hogy a szerverhost a mosh-kliens UDP-adatcsomagokat küldjön egy helytelen címre, ami meghiúsította a csatlakozási kísérletet (javítva a 2012 októberében megjelent Mosh 1.2.3 verzióban).

K: Milyen a Mosh biztonsága az SSH-hoz képest?

Úgy gondoljuk, hogy a Mosh konzervatív tervezése azt jelenti, hogy a támadási felülete kedvezően hasonlít az olyan bonyolultabb rendszerekhez, mint az OpenSSL és az OpenSSH. A Mosh eddigi eredményei ezt igazolják. Végső soron azonban csak az idő fogja megmutatni, hogy mikor fedezik fel az első komoly biztonsági rést a Mosh-ban – vagy azért, mert végig ott volt, vagy azért, mert véletlenül került bele a fejlesztés során. Az OpenSSH-ban és az OpenSSL-ben több sebezhetőség volt, de ezeket régebb óta adják ki, és elterjedtebbek is.

Egy konkrét szempontból a Mosh protokoll biztonságosabb, mint az SSH-é: Az SSH a nem hitelesített TCP-re támaszkodik a biztonságos adatfolyam tartalmának továbbításához. Ez azt jelenti, hogy egy támadó egyetlen hamis “RST” szegmenssel véget vethet egy SSH-kapcsolatnak. Ezzel szemben a Mosh egy másik rétegben alkalmazza a biztonságot (minden egyes datagramot hitelesít), így egy támadó nem tud véget vetni egy Mosh-munkamenetnek, hacsak nem tudja folyamatosan megakadályozni, hogy a csomagok eljussanak a másik oldalra. Egy átmeneti támadó csak átmeneti, a felhasználó számára látható kiesést okozhat; amint a támadó távozik, a Mosh folytatja a munkamenetet.

A tipikus használatban azonban a Mosh az SSH-ra támaszkodik a munkamenet elején történő kulcscsere során, így a Mosh örökölni fogja az SSH gyengeségeit – legalábbis annyiban, amennyiben azok a rövid SSH munkamenetet érintik, amelyet egy hosszú ideig tartó Mosh munkamenet létrehozásához használnak.

K: Érinti-e a Mosh-t az OCB2 titkosítási mód elleni 2018-as támadások?

Nem tudunk róla, hogy a Mosh az OCB3-at használja. A tanulmány szerzői azt írják, hogy a támadás nem alkalmazható az OCB3-ra.

K: Miért használ a mosh AES-128-at a munkamenetkulcshoz, és nem AES-192-t vagy AES-256-ot?

• Az AES-128 több mint megfelelő hosszúságú kulcs egy munkamenetkulcshoz.
• Az OCB GYIK az AES-128-at ajánlja.
• Az AES-128 egy kicsit szebb, és nincs kitéve az AES-192-t és az AES-256-ot sújtó kapcsolódó kulcs elleni támadásoknak. (Schneier: “a 256 bites változat kulcsmenetrendje elég pocsék — amire már a 2000-es cikkünkben is rámutattunk –, de ez nem terjed ki a 128 bites kulcsú AES-re”. Lásd ezt a blogbejegyzést.)

K: A mosh működik az Amazon EC2-vel?

Igen, nagyszerűen működik, de ne felejtse el megnyitni a 60000-61000-es UDP portokat az EC2 tűzfalán.

K: Honnan tudom megállapítani, hogy a mosh megfelelően működik-e?

A mosh user@server futtatása után, ha sikeres, akkor a távoli gép bejelentkezési héjába kerülsz. Ha ellenőrizni akarod, hogy a mosh-t használják-e az ssh helyett, próbáld meg a Ctrl-^ Ctrl-Z beírásával felfüggeszteni a munkamenetet (mosh 1.2.4 vagy újabb verziójú klienssel). A fg futtatása ezután visszatér.

K: Mi a különbség a mosh, a mosh-client és a mosh-server között? Melyiket használjam?

A mosh parancs egy wrapper script, amelyet úgy terveztek, hogy a mosh elsődleges használati módja legyen. A legtöbb esetben egyszerűen csak helyettesítsd az “ssh”-t “mosh”-ra a parancssorodban. A színfalak mögött a mosh wrapper script SSH kapcsolatot létesít a szerverrel, elindítja a mosh-server parancsot, majd lezárja az SSH kapcsolatot. Ezután elindítja a mosh-client futtatható programot a kliensen, átadva neki a szükséges információkat, hogy csatlakozhasson az újonnan létrehozott mosh-server példányhoz.

Normál használat esetén a mosh-client és mosh-server programokat nem kell közvetlenül futtatni.

K: Hogyan futtathatom külön a mosh klienst és a szervert?

Ha a mosh wrapper script nem működik neked, megpróbálhatod külön-külön futtatni a mosh-client és mosh-server programokat a kapcsolat kialakításához. Ez hasznos hibakeresési technika lehet.

1. Jelentkezzen be a távoli állomáson, és futtassa a mosh-server programot.

Ez a következő kimenetet fogja adni:

$ 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. A helyi állomáson futtassa:

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

melyikben a “key” a mosh-server által kiírt 22 bájtos karakterlánc (ebben a példában “4NeCCgvZFe2RnPgrcU1PQw”), a “remote-PORT” a szerver által megadott portszám (ebben az esetben 60004), a “remote-IP” pedig a szerver IP-címe. A szerver IP-címét a “host remotehost” paranccsal tudod megnézni.

3. Ha minden jól megy, akkor működőképes Mosh-kapcsolatod lesz. Az információ arról, hogy hol sikertelen a folyamat, segíthet nekünk abban, hogy kiderítsük, miért nem működik neked a Mosh.

K: A mosh-kiszolgálóval FreeBSD-n vagy OS X-en néha furcsa színproblémákat kapok. Mi a baj?

Ezt a hibát a Mosh 1.2-ben javítottuk. Köszönet Ed Schoutennek és Peter Jeremy-nek, hogy lenyomozták ezt.

K: Hogyan járulhatok hozzá a mosh-hoz?

Szívesen fogadjuk a hozzájárulásodat! Kérjük, csatlakozz hozzánk a #mosh csatornán a Freenode IRC-n, látogass meg minket a GitHubon, vagy írj nekünk a [email protected] e-mail címre. Ha hozzá szeretnél járulni a kódbázisunkhoz, kérjük, forkold a GitHubon lévő repository-t, és nyiss ott egy pull requestet.

K: Ki segített a mosh létrehozásában?

Hálásak vagyunk a segítségért és támogatásért:

• Hari Balakrishnan, aki tanácsot adott ehhez a munkához és kitalálta a nevet.
• Paul Williams, akinek visszafejtett vt500 állapotdiagramja a Mosh parser alapja.
• A névtelen felhasználók, akik munkamenetnaplókkal járultak hozzá a Mosh prediktív visszhangjának hangolásához és méréséhez.
• Nickolai Zeldovich a Mosh kutatási cikkhez fűzött hasznos megjegyzéseiért.
• Richard Stallman a SUPDUP helyi szerkesztési protokoll képességeiről folytatott hasznos vitáért.
• Nelson Elhage
• Christine Spang
• Stefie Tellex
• Joseph Sokol-nak
• .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 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