Desktop di condivisione Gnome 3.10: come configurare il tipo di sicurezza per VNC?

I fatti: avevo una configurazione per condividere il mio desktop che funzionava fino al recente aggiornamento del desktop Gnome per usare sgnome-shell 3.10. Mi collegavo alla mia macchina da Windows usando TightVNC e ha funzionato perfettamente fino a ieri (2014-19-1).

Ora la connessione dal lato Windows non riesce ( accesso completo in pastebin ) con questo errore:

Quale scavo del registro è:

[ 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.

La parte "condivisione" è configurata come dovrebbe, come puoi vedere qui:

La diagnosi: sembra che l'aggiornamento abbia cambiato il tipo di sicurezza con uno nuovo non conosciuto da tightVNC (è successo in passato).

La domanda: fino a quando TightVNC (e il resto del mondo) raggiungono , è possibile configurare il server VNC interno per utilizzare il precedente tipo di sicurezza?

Soluzione reale : ora sto usando SSVNC sul computer Windows e x11vnc sul server Linux. Funziona con bVNC anche su Android. Hai bisogno di un po 'di esperienza per farlo funzionare, quindi segui le istruzioni qui:

Su Linux (segui le istruzioni che x11vnc ti sta dando, è prolisso ma vale la pena leggere):

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

(dovrai inserire l'ultimo in uno dei tuoi script di avvio del login, o altro. Non usare una passphrase sul certificato SSL generato. Sto usando la porta 6000 per non scherzare con vino).

Su Windows: installa il client binario da qui .

Connettiti e goditi una connessione crittografata (lenta ...).

Risposta parziale: (pubblicato per aiutare altre persone, NON CONSIGLIATO ); Spero che ci saranno altre risposte alla domanda --- Segnerò questa risposta come quella giusta in quanto non ci sono soluzioni per ora).

Il problema è emerso quando il progetto Vino ha deciso di passare per richiedere la crittografia per impostazione predefinita --- sfortunatamente, l'unico tipo di crittografia supportato dal vinoserver (tipo 18) non è supportato dalla maggior parte dei visualizzatori Windows, Android e iOS. Per quello che so, solo il vinagrevisualizzatore basato su Linux lo supporta.

Ho segnalato un bug al progetto Vino, sia a monte che nel launchpad su questo problema; guarda lì per maggiori dettagli. Fondamentalmente, sembra che non ci sia sufficiente potenza di sviluppo per implementare più tipi di crittografia sul server (abbastanza giusto).

Ciò significa che puoi tornare al precedente comportamento non sicuro disabilitando la crittografia per l'intero livello VNC usando in dconf-editorquesto modo:

Un grosso avviso che significa che tutto ciò che scrivi è visibile in chiaro nella rete. Password incluse.

Posso farlo perché la connessione avviene davvero attraverso un tunnel SSH crittografato e non ci sono altri utenti locali sul computer remoto --- ma anche in questo caso, se qualcuno riesce ad accedere al tuo computer, può leggere tutti i tuoi segreti annusando 127.0.0.1 ...

Una riga di crittografia UNSAFE disattiva il comando per 16.04

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

quindi TigerVNC e realvnc funzionano da Windows.

Come ha sottolineato Rmano , tuttavia, fallo solo se la tua connessione è già crittografata su un altro livello.

Trovato con dconf dump .

Esiste anche una richiesta di compatibilità sul lato TigerVNC: https://github.com/TigerVNC/tigervnc/issues/307

Individua rapidamente la posizione da modificare - avvia dconf-editor, digita ctl f - digita 5900 - premi invio e verrà visualizzata l'area corretta per disabilitare la crittografia. Se più sezioni hanno 5900, premere next per trovare la prossima occorrenza.