Mosh

Q: Kto napisał Mosh?

Mosh został napisany przez Keitha Winsteina, wraz z Andersem Kaseorgiem, Quentinem Smithem, Richardem Tibbettsem, Keeganem McAllisterem i Johnem Hoodem.

P: Dlaczego kolejny protokół zdalno-terminalny?

Praktyczne opóźnienia w Internecie rosną wraz z rozwojem zjawiska bufferbloat i wyrafinowanych łączy bezprzewodowych, które optymalizują przepustowość w stosunku do opóźnień. A roaming jest bardziej powszechny niż kiedykolwiek, teraz, gdy laptopy i urządzenia przenośne w dużej mierze wyparły komputery stacjonarne. SSH jest świetne, ale frustrujące w użyciu, gdy chcesz zmienić adres IP, masz opóźnione łącze lub podejrzane połączenie.

Co więcej, TELNET miał kilka dobrych cech – tryb local-echo i dobrze zdefiniowany sieciowy terminal wirtualny. Nawet dziś SSH nie obsługuje poprawnie UTF-8 end-to-end w systemie POSIX.

P: Czy zasady mosh są istotne dla innych aplikacji sieciowych?

Sądzimy, że tak. Zasady projektowania, za którymi opowiada się Mosh, są konserwatywne: ostrzeganie użytkownika, jeśli wyświetlany stan jest nieaktualny, serializacja i checkpointing wszystkich transakcji tak, że jeśli nie ma ostrzeżeń, użytkownik wie, że każda wcześniejsza transakcja zakończyła się sukcesem, oraz obsługa oczekiwanych zdarzeń (takich jak roaming z jednej sieci WiFi do innej) z wdziękiem.

Nie wydają się one zbyt kontrowersyjne, ale wymyślne aplikacje, takie jak Gmail w Chromie lub na Androidzie, nadal zachowują się okropnie na podejrzanych połączeniach lub po zmianie adresu IP. (Czy kiedykolwiek zdarzyło Ci się, że Gmail zostawił wiadomość e-mail w „Wysyłanie…” przez dziesięć godzin, podczas gdy wesoło pobierał nową pocztę i nie wskazywał żadnego błędu? My też.) Sądzimy, że zastosowanie tych wartości może znacznie poprawić wiele interfejsów użytkownika sieci.

P: Otrzymuję komunikat „mosh wymaga locale UTF-8”. Jak mogę to naprawić?

Aby zdiagnozować problem, uruchom locale na lokalnym terminalu, a następnie ssh remotehost locale. Aby użyć Mosh, obie strony połączenia będą musiały mieć ustawienia UTF-8, takie jak LC_CTYPE="en_US.UTF-8".

W wielu systemach SSH przekaże zmienne środowiskowe związane z lokalizacją, które są następnie dziedziczone przez mosh-server. Jeśli ten mechanizm zawiedzie, Mosh (od wersji 1.2) sam przekaże te zmienne. Jeśli żaden z tych mechanizmów nie powiedzie się, możesz zrobić coś w rodzaju

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

Jeśli en_US.UTF-8 nie istnieje na zdalnym serwerze, możesz zastąpić je locale UTF-8, które istnieją. Może być również konieczne ustawienie LANG lokalnie, aby skorzystać z mosh-client. Możliwe, że maszyny lokalne i zdalne będą potrzebować różnych nazw locale. Zobacz także ten bilet GitHub.

P: Co oznacza komunikat „Nic nie odebrano z serwera na porcie UDP 60003”?

To oznacza, że mosh był w stanie pomyślnie uruchomić mosh-server na zdalnej maszynie, ale klient nie jest w stanie komunikować się z serwerem. Ogólnie oznacza to, że jakiś rodzaj firewalla blokuje pakiety UDP pomiędzy klientem a serwerem. Jeśli musiałeś przekierować port TCP 22 na NAT dla SSH, będziesz musiał również przekierować porty UDP. Mosh użyje pierwszego dostępnego portu UDP, zaczynając od 60001, a kończąc na 60999. Jeśli zamierzasz mieć tylko kilka równoczesnych sesji na serwerze, możesz przekazać mniejszy zakres portów (np. 60000 do 60010).

Narzędzia takie jak netstat, netcat, socat i tcpdump mogą być przydatne do usuwania problemów z siecią i zaporą.

Problem ten może być również wynikiem błędu w glibc 2.22, który wpływa na programy łączące się z protobuf i utempter oraz używające agresywnych flag utwardzania kompilatora. (Wpis w bugtrackerze glibc, jak również wpis w bugtrackerze Mosh.) Problem powoduje, że mosh-server ulega segfaultowi natychmiast po uruchomieniu. Wierzymy, że udało nam się obejść ten problem w Mosh 1.2.6, ale prosimy o zgłoszenie błędu, jeśli okaże się inaczej.

P: Dlaczego wszędzie nalegacie na UTF-8?

Naprawdę nie jesteśmy gorliwymi zwolennikami UTF-8. Ale o wiele łatwiej jest poprawnie zaimplementować jeden emulator terminala niż próbować robić to dobrze w wielu trudnych przypadkach brzegowych. (To właśnie próbuje zrobić GNU screen i z naszego doświadczenia wynika, że prowadzi to do bardzo trudnych do debugowania sytuacji). Tak więc mosh po prostu nie uruchomi się, dopóki użytkownik nie skonfiguruje wszystkiego dla czystej ścieżki UTF-8. Może to być irytujące, ale prawdopodobnie zmniejsza frustrację na drodze do celu. (Niestety 8-bitowy vt220 i UTF-8 vt220 są różnymi i niekompatybilnymi typami terminali; UTF-8 wchodzi pod maszynę stanów vt220.)

Q: Jak używać innego portu SSH (nie 22)?

Od wersji Mosh 1.2 można przekazywać argumenty do ssh w następujący sposób:

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

Alias hosta można też skonfigurować w ~/.ssh/config za pomocą dyrektywy Port. Mosh również będzie to respektował.

P: Otrzymuję komunikat 'mosh-server not found’.

Upewnij się, że mosh jest zainstalowany na kliencie, a mosh (lub przynajmniej mosh-server) jest zainstalowany na serwerze, z którym próbujesz się połączyć. Ponadto oczekuje się, że serwer będzie dostępny pod domyślnym loginem PATH, co zwykle nie jest prawdą na serwerach OS X i BSD lub jeśli zainstalujesz mosh-server w swoim katalogu domowym. W takich przypadkach należy zapoznać się z instrukcją „Ścieżka binarna poza serwerem” w sekcji Użytkowanie, powyżej.

P: SSH uwierzytelnia się przy użyciu biletów Kerberos, ale Mosh prosi mnie o hasło.

W niektórych konfiguracjach, SSH kanonizuje nazwę hosta przed przekazaniem jej do wtyczki Kerberos GSSAPI. Przerywa to działanie Mosh, ponieważ początkowe wyszukiwanie DNS jest wykonywane przez skrypt wrappera Mosh. Aby to obejść, należy wywołać Mosh jako

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

To często zawodzi przy konfiguracji DNS typu round-robin. W takim przypadku prawdopodobnie najlepiej jest wybrać konkretnego hosta z puli round-robin.

Q: Dlaczego bufor przewijania mojego terminala jest niekompletny?

Mosh synchronizuje tylko widoczny stan terminala. Śledzimy ten problem; zobacz ten problem i inne, które są z nim powiązane. Na razie, obejściem jest użycie screen lub tmux po stronie zdalnej.

Q: Jak uzyskać 256 kolorów?

Upewnij się, że uruchamiasz mosh w terminalu, który reklamuje się jako obsługujący 256 kolorów. (To zazwyczaj oznacza, że TERM będzie xterm-256color lub screen-256color-bce.)

Q: Jak wpisać C-^, domyślny znak ucieczki Mosha?

Na klawiaturach z układem amerykańskim, może to być wpisane jako Ctrl-Shift-6, lub często jako Ctrl-6 (to zależy od twojego systemu operacyjnego i emulatora terminala). Na klawiaturach nieamerykańskich, często trudno jest znaleźć właściwy klawisz, a czasami nie jest on w ogóle dostępny. Jeśli twoja klawiatura ma martwy klawisz z akcentem-circumflex, to raczej nie jest to właściwy klawisz. Ctrl-6 czasami jednak działa. Jeśli nie możesz wpisać tego znaku, będziesz musiał ustawić zmienną MOSH_ESCAPE_KEY; zobacz stronę man Mosh, aby uzyskać szczegóły.

P: Jak mogę sprawić, by serwer automatycznie czyścił uśpione sesje?

Zobacz wpisy dla MOSH_SERVER_NETWORK_TMOUT i MOSH_SERVER_SIGNAL_TMOUT na stronie man mosh-server(1).

P: Jakie są dotychczasowe osiągnięcia Mosha w zakresie bezpieczeństwa?

Mosh 1.0 został wydany w marcu 2012 roku. Od wydania Mosh 1.3.2 w lipcu 2017 roku, o ile deweloperzy są świadomi:

• W ciągu ostatnich czterech lat w Mosh nie zgłoszono żadnych luk w zabezpieczeniach jakiegokolwiek rodzaju (większych lub mniejszych).
• Nigdy nie zgłoszono żadnych poważnych luk w zabezpieczeniach systemu Mosh. Definiujemy poważne luki w zabezpieczeniach jako eskalację uprawnień, zdalne wykonanie kodu, odmowę usługi przez stronę trzecią, itp.
• Dwa problemy z odmową usługi zostały odkryte i naprawione w wydaniach z 2012 roku. Jeden z nich umożliwiał serwerowi mosh powodowanie nadmiernego obciążenia procesora przez klienta mosh (CVE-2012-2385, poprawiony w Mosh1.2.1, wydanym w maju 2012). Inny problem umożliwiał serwerowi-hostowi spowodowanie, że klient mosh wysyłał datagramy UDP pod nieprawidłowy adres, udaremniając próbę połączenia (poprawiono w wersji Mosh 1.2.3, wydanej w październiku 2012).

P: Jak bezpieczeństwo Mosha ma się do bezpieczeństwa SSH?

Uważamy, że konserwatywny projekt Mosha oznacza, że jego powierzchnia ataku wypada korzystnie w porównaniu z bardziej skomplikowanymi systemami, takimi jak OpenSSL i OpenSSH. Dotychczasowe osiągnięcia Mosha to potwierdzają. Ostatecznie jednak, tylko czas pokaże, kiedy zostanie odkryta pierwsza poważna luka w zabezpieczeniach Mosha – albo dlatego, że istniała ona od samego początku, albo dlatego, że została dodana nieumyślnie w trakcie rozwoju systemu. OpenSSH i OpenSSL mają więcej luk w zabezpieczeniach, ale są one również dłużej dostępne i bardziej rozpowszechnione.

Pod jednym konkretnym względem, protokół Mosh jest bezpieczniejszy niż SSH: SSH opiera się na nieuwierzytelnionym TCP do przenoszenia zawartości bezpiecznego strumienia. Oznacza to, że atakujący może zakończyć połączenie SSH za pomocą jednego fałszywego segmentu „RST”. W przeciwieństwie do tego, Mosh stosuje swoje zabezpieczenia na innej warstwie (uwierzytelniając każdy datagram), więc atakujący nie może zakończyć sesji Mosh, chyba że jest w stanie w sposób ciągły uniemożliwiać pakietom dotarcie do drugiej strony. Przelotny napastnik może spowodować jedynie przelotną przerwę widoczną dla użytkownika; gdy napastnik odejdzie, Mosh wznowi sesję.

Jednakże w typowym użyciu Mosh opiera się na SSH w celu wymiany kluczy na początku sesji, więc Mosh odziedziczy słabości SSH – przynajmniej w zakresie, w jakim wpływają one na krótką sesję SSH, która jest używana do ustanowienia długotrwałej sesji Mosh.

P: Czy Mosh jest dotknięty atakami z 2018 r. na tryb szyfrowania OCB2?

Nie, o czym wiemy-Mosh używa OCB3. Autorzy tapety piszą, że atak nie dotyczy OCB3.

P: Dlaczego mosh używa AES-128 dla klucza sesyjnego, a nie AES-192 lub AES-256?

• AES-128 jest więcej niż odpowiednią długością klucza dla klucza sesyjnego.
• OcB FAQ zaleca AES-128.
• AES-128 jest trochę ładniejszy i nie podlega atakom typu related-key, które trapią AES-192 i AES-256. (Schneier: „harmonogram klucza dla wersji 256-bitowej jest dość kiepski — coś, na co zwróciliśmy uwagę w naszym artykule z 2000 roku — ale nie rozciąga się na AES z kluczem 128-bitowym.” Zobacz ten wpis na blogu.)

P: Czy mosh działa z Amazon EC2?

Tak, działa świetnie, ale proszę pamiętać o otwarciu portów UDP 60000-61000 na zaporze EC2.

P: Jak sprawdzić, czy mosh działa poprawnie?

Po uruchomieniu mosh user@server, jeśli się powiedzie, zostaniesz przeniesiony do swojej powłoki logowania na zdalnej maszynie. Jeśli chcesz sprawdzić, czy mosh jest używany zamiast ssh, spróbuj wpisać Ctrl-^ Ctrl-Z, aby zawiesić sesję (z mosh 1.2.4 lub nowszym na kliencie). Uruchomienie fg spowoduje powrót.

P: Jaka jest różnica między mosh, mosh-client i mosh-server? Którego z nich mam użyć?

Polecenie mosh jest skryptem opakowującym, który został zaprojektowany jako podstawowy sposób używania mosh. W większości przypadków można po prostu zastąpić „ssh” przez „mosh” w wierszu poleceń. Za kulisami, skrypt mosh będzie SSH do serwera, uruchomi mosh-server, a następnie zamknie połączenie SSH. Następnie uruchomi plik wykonywalny mosh-client na kliencie, przekazując mu informacje niezbędne do połączenia się z nowo utworzoną instancją mosh-server.

W normalnym użyciu, mosh-client i mosh-server nie muszą być uruchamiane bezpośrednio.

Q: Jak mogę uruchomić klienta i serwer mosh osobno?

Jeśli skrypt mosh nie działa, możesz spróbować uruchomić osobno programy mosh-client i mosh-server, aby utworzyć połączenie. Może to być przydatna technika debugowania.

1. Zaloguj się do zdalnego hosta i uruchom program mosh-server.

Wyświetli on następujące dane wyjściowe:

$ 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. Na lokalnym hoście uruchom:

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

gdzie „key” to 22-bajtowy ciąg znaków wydrukowany przez mosh-server (w tym przykładzie „4NeCCgvZFe2RnPgrcU1PQw”), „remote-PORT” to numer portu podany przez serwer (w tym przypadku 60004), a „remote-IP” to adres IP serwera. Możesz sprawdzić adres IP serwera wpisując „host remotehost”.

3. Jeśli wszystko pójdzie dobrze, powinieneś mieć działające połączenie Mosh. Informacje o tym, gdzie proces się nie powiódł, mogą nam pomóc w ustaleniu, dlaczego Mosh nie działa dla Ciebie.

P: Z serwerem mosh na FreeBSD lub OS X czasami mam dziwne problemy z kolorami. Co jest nie tak?

Ten błąd został naprawiony w Mosh 1.2. Podziękowania dla Eda Schoutena i Petera Jeremy’ego za wytropienie go.

P: Jak mogę przyczynić się do rozwoju mosh?

Witamy Twój wkład! Dołącz do nas na kanale #mosh na Freenode IRC, odwiedź nas na GitHubie lub wyślij e-mail [email protected]. Aby wnieść wkład do naszej bazy kodu, rozwidl repozytorium na GitHubie i otwórz tam żądanie ściągnięcia.

P: Kto pomógł w tworzeniu mosh?

Jesteśmy bardzo wdzięczni za pomoc i wsparcie od:

• Hari Balakrishnan, który doradzał w tej pracy i wymyślił nazwę.
• Paul Williams, którego odwrócony diagram stanów vt500 jest podstawą parsera Mosh.
• Anonimowi użytkownicy, którzy dostarczyli dzienniki sesji do dostrojenia i zmierzenia echa predykcyjnego Mosh.
• Nickolai Zeldovich za pomocne komentarze do pracy badawczej Mosh.
• Richard Stallman za pomocną dyskusję na temat możliwości protokołu SUPDUP Local Editing Protocol.
• Nelson Elhage
• Christine Spang
• Stefie Tellex
• Joseph Sokol-.Margolis
• Waseem Daher
• Bill McCloskey
• Austin Roach
• Greg Hudson
• Karl Ramm
• Aleksander 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

.