.png)
Posso ssh
acessar minha área de trabalho no trabalho e trabalhar na linha de comando, mas gostaria de usar um protocolo de área de trabalho remota para verificar alguns dos programas que deixei abertos e em execução.
Não configurei permissão para usar um cliente de área de trabalho remota (por exemplo, tsclient) na área de trabalho, portanto, minhas solicitações de conexão foram recusadas (veja a imagem).
As instruções dadas em umpergunta anteriorsugiro que o seguinte deve funcionar:
gconftool-2 -s -t bool /desktop/gnome/remote_access/enabled true
/usr/lib/vino/vino-server
Mas eu entendo isso:
(30/07/2011 11:25:35 PM Autoprobing TCP port in (all) network interface
30/07/2011 11:25:35 PM Listening IPv6://[::]:5900
30/07/2011 11:25:35 PM Listening IPv4://0.0.0.0:5900
30/07/2011 11:25:35 PM Autoprobing selected port 5900
30/07/2011 11:25:35 PM Advertising security type: 'TLS' (18)
30/07/2011 11:25:35 PM Advertising authentication type: 'No Authentication' (1)
30/07/2011 11:25:35 PM Advertising security type: 'No Authentication' (1)
Estou fazendo algo errado?
É possível fazer ssh e conceder as permissões necessárias para usar o tsclient?
Responder1
Desde que você tenha configurado seu servidor e cliente ssh para aceitar o encaminhamento X, podemos iniciar o Vino Preferences Manager com o seguinte comando:
ssh -X <remote>
user@remote:~$ vino-preferences
Com isso podemos habilitar o servidor vino e alterar as configurações, incluindo a senha VNC.
Responder2
Você não está fazendo nada de errado, mas está usando o software errado. Bastante compreensível. O que foi chamado de “área de trabalho remota” no Ubuntu nunca foi concebido para ser uma solução de área de trabalho remota. O objetivo era ser uma forma de compartilhar sua área de trabalho em execução com outra pessoa. Eu registrei um bug e parece ter sido corrigido porque agora foi renomeado para "Compartilhamento de área de trabalho", que é uma descrição muito melhor.
Mas mesmo que fosse possível, não seria recomendável. VNC é um protocolo muito lento e existem alternativas muito melhores:
- XRDP é um servidor de protocolo de área de trabalho remota para X. É mal documentado e um tanto complicado de configurar. A vantagem é que você pode usar o cliente de área de trabalho remota no Windows para se conectar a ele, bem como o tsclient que é instalado por padrão no Ubuntu.http://www.xrdp.org/
- Máquina NX. Este é um sistema de desktop remoto muito eficiente e fácil de usar. É de código fechado, construído em suas próprias bibliotecas NX de código aberto. Eles fornecem um servidor que você pode usar gratuitamente se apenas dois usuários tiverem permissão para se conectar e estiver limitado a duas conexões por vez. Eles vendem outros serviços sem essas limitações. Seu cliente é gratuito e está disponível para diversos sistemas operacionais. Eles também têm um plugin java para que você possa iniciar sessões a partir de um navegador da web. Existe um cliente de código aberto chamado OpenNX que é compatível com o servidor deles, mas eu ainda não tentei. Máquina:http://www.nomachine.com/OpenNX:http://opennx.net/
- O FreeNX pretende ser um substituto direto do Nomachine NX Server, baseado nas bibliotecas NX de código aberto. É compatível com seu cliente e com o cliente OpenNX. É fácil de instalar e usar.http://freenx.berlios.de/
- X2Go. Esse é meu favorito. É baseado nas bibliotecas Nomachines NX e seu servidor é de código aberto. Eles possuem um plugin para Firefox que permite executar uma sessão diretamente no navegador. Eles também têm suporte para PulseAudio, o que os outros não têm. O cliente deles é muito bom e pode ser usado como gerenciador de display.http://www.x2go.org/
Todas são soluções muito boas, mas recomendo que você as experimente na ordem inversa e pare quando encontrar uma que funcione bem. Ou seja, primeiro x2go, depois freenx, etc.
Responder3
Você também pode instalar o x11vnx e executá-lo após fazer login via ssh.
Mas primeiro tentarei a solução proposta por Takkat. Na maioria dos casos, funcionará imediatamente.