Gnome 3.10 compartilhando desktop - como configurar o tipo de segurança para VNC?

18

Os fatos: Eu tinha uma configuração para compartilhar minha área de trabalho que funcionou até a atualização recente da área de trabalho do Gnome para usar o sgnome-shell 3.10. Eu costumava me conectar à minha máquina de um Windows usando o TightVNC e funcionava perfeitamente até ontem (2014-19-1).

Agora a conexão do lado do Windows está falhando ( login completo em pastebin ) com este erro:

Que cavando o log é:

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

A parte "compartilhamento" está configurada como deveria, como você pode ver aqui:

O diagnóstico: Parece que a atualização mudou o tipo de segurança para um novo não conhecido por tightVNC (aconteceu no passado).

A pergunta: até o TightVNC (e o resto do mundo) alcança , é possível configurar o servidor VNC interno para usar o tipo de segurança anterior?

    
por Rmano 20.01.2014 / 20:37

3 respostas

14

Solução real : agora estou usando SSVNC na máquina do Windows e < href="https://help.ubuntu.com/community/VNC/Servers"> x11vnc no servidor linux. Funciona com bVNC no android também. Você precisa de um pouco de experiência para fazer isso funcionar, portanto, uma breve instrução aqui:

No Linux (siga as instruções que x11vnc está dando a você, é detalhado, mas vale a pena ser lido):

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

(você terá que colocar o último em um dos seus scripts de inicialização de login, ou qualquer outra coisa. Não use uma frase secreta no certificado SSL gerado. Estou usando a porta 6000 para não mexer com o vino).

No Windows: Instale o cliente binário aqui .

Conecte-se e desfrute de uma conexão criptografada (lenta ...).

Resposta parcial: (postada para ajudar outras pessoas, NÃO RECOMENDADO ); Espero que haja outras respostas para a pergunta - vou marcar esta resposta como a solução certa, já que não há solução até agora).

O problema surgiu quando o projeto Vino decidiu mudar para requer criptografia por padrão - - infelizmente, o único tipo de criptografia suportado pelo vino server (tipo 18) é não suportado pela maioria dos visualizadores do Windows, Android e iOS. Pelo que sei, apenas o vinagre viewer baseado em Linux suporta isso.

Eu relatei um bug para o projeto Vino, ambos upstream e em launchpad sobre este problema; olhe lá para mais detalhes. Basicamente, parece que não há poder de desenvolvedor suficiente para implementar mais tipos de criptografia no servidor (bastante justo).

Isso significa que você pode voltar ao comportamento anterior, inseguro desabilitando a criptografia para toda a camada do VNC usando dconf-editor da seguinte forma:

Aviso importante significa que tudo o que você digita está visível em clear na rede. Senhas incluídas.

Eu posso fazer isso porque a conexão é realmente através de um túnel SSH criptografado e não há outros usuários locais na máquina remota --- mas mesmo nesse caso, se alguém conseguir acessar a sua máquina, eles poderão ler todos os seus segredos farejando 127.0.0.1 ...

    
por Rmano 20.01.2014 / 20:49
4

Um comando de desativação de criptografia UNSAFE do liner para 16.04

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

o TigerVNC e o realvnc funcionam no Windows.

No entanto, como Rmano indicou, apenas faça isso se sua conexão já estiver criptografada em outra camada.

Encontrado com dconf dump .

Há também uma solicitação de compatibilidade no lado do TigerVNC: link

    
0

Localize rapidamente o local para editar - inicie o editor do dconf, digite ctl f - type 5900 - pressione enter e a área apropriada para desabilitar a criptografia será exibida. Se várias seções tiverem 5900, pressione próximo para encontrar a próxima ocorrência.

    
por Stuart Rothrock 06.04.2014 / 01:16

Tags