Pulpit współdzielący Gnome 3.10 - jak skonfigurować typ zabezpieczeń dla VNC?

Fakty: Miałem konfigurację udostępniania pulpitu, która działała do ostatniej aktualizacji pulpitu Gnome, aby używać sgnome-shell 3.10. Łączyłem się z moją maszyną z Windowsa za pomocą TightVNC i działała bezbłędnie do wczoraj (2014-19-1).

Teraz połączenie ze strony systemu Windows nie działa ( pełne logowanie do pastebin ) z tym błędem:

Który to jest kopanie dziennika:

[ 5872/ 6448] 2014-01-20 12:11:18:247   List of security type is read
[ 5872/ 6448] 2014-01-20 12:11:18:247 : Security Types received (1): Unknown type (18)
[ 5872/ 6448] 2014-01-20 12:11:18:247   Selecting auth-handler
[ 5872/ 6448] 2014-01-20 12:11:18:247 + RemoteViewerCore. Exception: No security types supported. Server sent security types, but we do not support any of their.

Część „udostępnianie” jest skonfigurowana tak, jak powinna, jak widać tutaj:

Diagnoza: Wygląda na to, że aktualizacja zmieniła typ zabezpieczeń na nowy, nieznany przez tightVNC (zdarzało się to w przeszłości).

Pytanie: dopóki TightVNC (i reszta świata) nie dogoni , czy możliwe jest skonfigurowanie wewnętrznego serwera VNC do korzystania z poprzedniego typu bezpieczeństwa?

Prawdziwe rozwiązanie : używam teraz SSVNC na komputerze z systemem Windows i x11vnc na serwerze z systemem Linux. Współpracuje również z bVNC na Androidzie. Potrzebujesz odrobiny wiedzy, aby to zadziałało, więc zwróć uwagę tutaj:

W systemie Linux (postępuj zgodnie z instrukcją, którą daje ci x11vnc, jest pełna, ale warto ją przeczytać):

x11vnc -storepasswd
x11vnc -forever -repeat -usepw -ssl -autoport 6000 

(będziesz musiał umieścić ostatni ze swoich skryptów startowych logowania itp. Nie używaj hasła do wygenerowanego certyfikatu SSL. Używam portu 6000, aby nie zadzierać z vino).

W systemie Windows: zainstaluj klienta binarnego z tego miejsca .

Połącz się i ciesz się (szyfrowanym ... powolnym ...) połączeniem.

Częściowa odpowiedź: (opublikowano w celu udzielenia pomocy innym osobom, NIE ZALECANE ); Mam nadzieję, że będą jeszcze inne odpowiedzi na pytanie --- Oznaczę tę odpowiedź jako właściwą, ponieważ do tej pory nie ma rozwiązania).

Problem pojawił się, gdy projekt Vino zdecydował się przełączyć, aby wymagać domyślnego szyfrowania --- niestety jedyny rodzaj szyfrowania obsługiwany przez vinoserwer (typ 18) nie jest obsługiwany przez większość przeglądarek Windows, Android i iOS. Z tego, co wiem, vinagreobsługuje go tylko przeglądarka oparta na systemie Linux .

Zgłosiłem błąd do projektu Vino, zarówno w górę , jak iw starterze, dotyczący tego problemu; poszukaj tam więcej szczegółów. Zasadniczo wydaje się, że nie ma wystarczającej mocy programisty, aby zaimplementować więcej typów szyfrowania na serwerze (wystarczająco uczciwie).

Oznacza to, że możesz wrócić do poprzedniego, niebezpiecznego zachowania, wyłączając szyfrowanie dla całej warstwy VNC, korzystając z dconf-editornastępującego sposobu:

Duża informacja o treści oznacza, że ​​wszystko, co wpisujesz, jest wyraźnie widoczne w sieci. Hasła w zestawie.

Mogę to zrobić, ponieważ połączenie odbywa się za pośrednictwem zaszyfrowanego tunelu SSH i na zdalnym komputerze nie ma innych lokalnych użytkowników --- ale nawet w tym przypadku, jeśli ktoś zdoła uzyskać dostęp do twojego komputera, może odczytać wszystkie twoje sekrety wąchając 127.0.0.1 ...

Jedno liniowe szyfrowanie UNSAFE wyłącz polecenie 16.04

dconf write /org/gnome/desktop/remote-access/require-encryption false

następnie TigerVNC i realvnc działają w systemie Windows.

Jak zauważył Rmano , rób to tylko wtedy, gdy twoje połączenie jest już zaszyfrowane na innej warstwie.

Znaleziono z dconf dump.

Istnieje również żądanie zgodności po stronie TigerVNC: https://github.com/TigerVNC/tigervnc/issues/307

Szybko zlokalizuj lokalizację do edycji - uruchom edytor dconf, wpisz ctl f - typ 5900 - naciśnij enter i wyświetli się odpowiedni obszar do wyłączenia szyfrowania. Jeśli wiele sekcji ma 5900, naciśnij przycisk Dalej, aby znaleźć następne wystąpienie.