Ativar Logins de Vários Usuários com o VNC

Ajude seus usuários a acessarem um sistema linux de vários usuários de qualquer lugar

O VNC (Virtual Network Computing) é uma ferramenta popular que fornece acesso remoto a computadores. A configuração normal do VNC é otimizada para estações de trabalho de usuário único e o login na porta do VNC oferece acesso direto à área de trabalho de um único usuário. No entanto, essa configuração é inadequada em computadores de vários usuários. Felizmente, há uma alternativa. Vinculando o VNC ao servidor XDMCP (X Display Manager Control Protocol) normal de um computador Linux, o acesso à porta do VNC possibilita que os usuários forneçam seus nomes de usuário e senhas, permitindo assim que uma única instância do servidor VNC lide com vários logins de usuário.

Roderick W. Smith, Consultant and author

Photo of Roderick W. SmithRoderick W. Smith é consultor e autor de mais de dez livros sobre UNIX e Linux, incluindo The Definitive Guide to Samba 3, Linux in a Windows World e Linux Professional Institute Certification Study Guide. Ele também é o autor do software de particionamento GPT fdisk. Atualmente, ele reside em Woonsocket, Rhode Island, e pode ser contactado em rodsmith@rodsbooks.com.



11/Mai/2012

Arquiteturas do servidor VNC e X

O Linux® usa o X Window System (abreviação, X ) como sua interface gráfica com o usuário (GUI). O X é uma GUI incomum por vários aspectos, um deles é porque é inerentemente ativado por rede. Um servidor X é literalmente um programa de servidor de rede. Os programas de servidor de rede fornecem aos programas clientes acesso aos recursos locais; isso também acontece com um servidor X. A singularidade é que os "recursos locais", no caso de um servidor X, são o monitor, teclado e mouse utilizados pelo usuário. Na configuração mais comum, os programas clientes do X são executados no mesmo computador do servidor. Desse modo, o LibreOffice, o GIMP (GNU Image Manipulation Program) ou outros programas são clientes do X que utilizam os protocolos de rede do X para aceitar a entrada do usuário e a saída do monitor para usuários no mesmo computador.

Entretanto, quando o X é usado em uma rede, o usuário se senta ao computador servidor X e os clientes do X são os programas que o usuário deseja executar em outro computador. Essa configuração requer um segundo protocolo de rede para iniciar a conexão. Esse segundo protocolo pode ser telnet, Shell Seguro (SSH) ou XDMCP (X Display Manager Control Protocol). O servidor desse protocolo de login é executado no computador cliente do X e o cliente de login remoto é executado no computador servidor X. O servidor de login remoto ativa os clientes do X que, por sua vez, entram em contato com o servidor X. Figura 1 descreve esse relacionamento. As setas tracejadas denotam a inicialização da sessão. (No caso do XDMCP, o cliente XDMCP é desenvolvido no programa do servidor X.)

Figura 1. O acesso remoto ao X requer um cliente e um servidor nos dois computadores
O acesso remoto ao X requer um cliente e um servidor nos dois computadores

Esse tipo de configuração funciona bem em muitas redes locais, mas tem suas desvantagens. Por exemplo, essa configuração requer a inicialização do protocolo de rede bidirecional, que pode não ser possível por meio de alguns firewalls ou roteadores de conversão de endereço de rede (NAT). (O SSH pode criar uma passagem nas sessões do X, evitando essa necessidade.) Além disso, embora os servidores do X estejam disponíveis para a maioria das plataformas, eles geralmente não são instalados em computadores que executam o Windows®. Por essas e outras razões, muitos locais preferem utilizar outro protocolo, o RFB (Remote Frame Buffer), que é implementado na família de programas do Virtual Network Computing (VNC).

O VNC é uma ferramenta de plataforma cruzada que pode fornecer acesso remoto ao Linux, UNIX®, Mac OS X, Windows e outros sistemas de qualquer tipo de cliente. Com ele, o usuário se senta ao computador do cliente e acessa um computador de servidor remoto. No Linux, o servidor VNC espelha o conteúdo da tela do servidor X local para o computador remoto ou inclui seu próprio servidor X, que pode operar independentemente daquele que gerencia a tela local. O resultado se parece com a Figura 2. Novamente, a seta tracejada indica a inicialização da sessão. Essa configuração elimina a necessidade da conexão de rede reversa e, como os clientes e servidores VNC existem para tantos sistemas operacionais, os usuários podem empregar um único programa cliente para acessar qualquer servidor.

Figura 2. Um servidor VNC inclui um servidor X que pode se comunicar com programas clientes X locais
Um servidor VNC inclui um servidor X que pode se comunicar com programas clientes X locais

A desvantagem do VNC é que a autenticação do RFB se baseia em senhas sem nomes de usuário. Dessa maneira, cada usuário deve ativar uma sessão de servidor VNC independente e se conectar a essa instância do VNC especificando o número da porta correto. Esse requisito pode ser tolerável em um sistema de usuário único, mas é extremamente inadequado em um computador de vários usuários.

Como solução alternativa para esse problema, é possível vincular as duas abordagens. É possível reconfigurar seu servidor XDMCP local para ajudar o servidor X integrado ao VNC a fornecer a autenticação de vários usuários ausente (a configuração resultante é parecida com Figura 3). A seta tracejada indica a inicialização da sessão. Agora, ao contatar o computador servidor do VNC, os usuários remotos do VNC poderão inserir seus nomes de usuário e senhas para acessar suas próprias sessões exclusivas do VNC, a fim de que o computador possa lidar com quantos usuários desejar.

Figura 3. A adição do XDMCP a uma configuração do VNC fornece flexibilidade extra
A adição do XDMCP a uma configuração do VNC fornece flexibilidade extra

Configurando seu servidor VNC

Há várias formas de ativar o VNC, entre elas: usando scripts, vinculando o VNC ao seu ambiente de área de trabalho usando ferramentas da área de trabalho e usando xinetd para receber conexões do VNC. Esta última abordagem é a descrita aqui, pois permite a ativação do VNC de forma que ele possa usar seu servidor XDMCP. Antes de detalhar como configurar o VNC para ser ativado por meio de xinetd, é preciso selecionar um servidor VNC.

Selecionando um Servidor VNC

Diversos programas do servidor VNC estão disponíveis. (Recursos fornece ponteiros para muitos deles.) Algumas das opções mais populares incluem: TightVNC, TigerVNC e RealVNC. Este artigo usa o TightVNC como exemplo. Infelizmente, os detalhes da configuração variam de um servidor para outro e também de uma distribuição para outra, portanto, pode ser necessário ajustar as instruções fornecidas aqui de acordo com seu software.

Instalando o xinetd

Muitas distribuições instalam o super servidor xinetd por padrão, mas outras não. Como o método descrito aqui usa o xinetd, é preciso instalá-lo como se ele ainda não estivesse instalado. Na maioria das distribuições, é possível instalar o xinetd utilizando o sistema do pacote, como o apt-get install xinetd em distribuições baseadas no Debian ou o zypper install xinetd no openSUSE.

Também pode ser necessário configurar o xinetd para ser executado. Geralmente, é possível executá-lo de forma ocasional utilizando seu script de inicialização do System V (SysV):

# /etc/init.d/xinetd start

A configuração do xinetd para ser executado automaticamente quando o computador é inicializado requer conhecimento dos métodos de script de inicialização para sua distribuição. Normalmente, um utilitário como o chkconfig (usado no Fedora, openSUSE e distribuições relacionadas), update-rc.d (usado no Debian e em distribuições relacionadas) ou rc-update (usado no Gentoo) são utilizados para executar a tarefa, como em:

# chkconfig xinetd on
# update-rc.d xinetd enable
# rc-update add xinetd default

Digite apenas um desses comandos ou localize um equivalente para sua distribuição.

Observe que xinetd pode se recusar a iniciar se não tiver nenhum serviço configurado. Desse modo, é possível adiar a ativação até que tenha configurado o xinetd para gerenciar seu servidor VNC.

Configurando o xinetd

Servidores que devem ser gerenciados pelo xinetd colocam os arquivos de configuração no diretório /etc/xinetd.d. Portanto, para configurar o xinetd para manipular o VNC, é preciso criar ou editar um arquivo com um nome como/etc/xinetd.d/vnc. (Em algumas distribuições, como openSUSE, o pacote do servidor VNC instala esse arquivo.) Lista 1 dá um exemplo.

Lista 1. Um Exemplo de Configuração do VNC para o xinetd
service vnc
{
   disable     = no
   socket_type = stream
   protocol    = tcp
   wait        = no
   user        = nobody
   server      = /usr/bin/Xvnc
   server_args = -inetd -once -query localhost -geometry 1024x768 -depth 16
   type        = UNLISTED
   port        = 5900
}

Essa entrada configura diversas opções do xinetd , sendo que a maioria delas deve ser mantida isolada. Aquelas que podem ser ajustadas incluem:

  • serviço. É possível executar o VNC em diversas portas com diferentes opções em cada, mas, se isso for feito, é preciso dar um nome de serviço diferente ao VNC para cada porta na primeira linha na Lista 1.
  • server. É preciso alterar essa entrada para apontar para o binário principal do servidor VNC, que geralmente é chamado de Xvnc.
  • server_args. Você quase certamente desejará alterar algumas dessas opções, conforme descrito brevemente.
  • port. O VNC usa portas numeradas como 5900 e acima. É possível executar o servidor com diferentes opções em portas diferentes. Caso isso seja feito, é preciso designar cada instância ao seu próprio número da porta.

A parte mais complicada da configuração do xinetd é definir os argumentos do servidor. É possível usar os argumentos na Lista 1 como um modelo, mas é possível alterar alguns deles:

  • -query localhost. Esta opção diz para o servidor X do VNC consultar o sistema do host local para a autenticação do XDMCP. É possível alterá-la caso queira um computador como uma retransmissão para acessar programas em outro.
  • -geometry 1024x768. A resolução virtual da sessão do VNC é configurada com esta opção. Observe que essa resolução não precisa ser semelhante à resolução do servidor X regular sendo executada no computador servidor. É possível criar diversas entradas executando em diferentes resoluções para permitir que os usuários efetuem login no servidor VNC usando a resolução conveniente para seus próprios sistemas locais.
  • -depth 16. Esta opção configura a intensidade de cor. Valores mais baixos podem produzir atualizações de exibição mais rápidas, mas ambientes de área de trabalho de cores elevadas podem sofrer com artefatos coloridos. Os valores válidos variam de 2 a 32.

Muitas outras opções estão disponíveis e algumas variam de um servidor VNC para outro. Consulte a documentação do seu servidor VNC para saber mais.


Configurando o Servidor XDMCP

A maioria das distribuições Linux configura seus servidores XDMCP para gerenciar a exibição local e nada mais. Para fornecer acesso remoto, é preciso reconfigurar seu servidor XDMCP para aceitar solicitações de acesso do servidor VNC que é executado no mesmo computador. Os detalhes variam de um servidor XDMCP para outro. Os três em uso mais comuns no Linux são o GDM (GNOME Display Manager), o LightDM (Light Display Manager) e o KDM (KDE Display Manager). Outros servidores XDMCP, como o XDM, exigem diferentes ajustes dos descritos aqui. De qualquer forma, depois de reconfigurar seu servidor XDMCP, será preciso reiniciá-lo.

Editando o arquivo de configuração do XDMCP

Caso não tenha certeza qual servidor XDMCP seu sistema utiliza, é possível identificá-lo pesquisando uma listagem de processos para a sequência dm, como em:

$ ps ax | grep dm
  929 ?        Ss     0:00 /usr/bin/kdm
  962 tty7     Ss+    0:19 /usr/bin/Xorg -br :0 vt7 -nolisten tcp -auth \
                           /var/lib/xdm/authdir/authfiles/A:0-pp4shb
30157 pts/3    S+     0:00 grep --color=auto dm

A primeira linha desta saída revela que o KDM está sendo executado, portanto, seria preciso editar o arquivo de configuração desse servidor para permitir que o VNC use o XDMCP. A maioria dos programas XDMCP possui arquivos de configuração que seguem um formato semelhante. Eles incluem seções que são identificadas por nomes de seção entre colchetes, como [xdmcp]. As linhas subsequentes ao nome da seção configuram as opções usando um sinal de igual, como em enable=true. Tablela 1 resume os nomes de arquivos de configuração, nomes de seção e opções que devem ser configurados para ativar o XDMCP em diversos servidores XDMCP comuns do Linux.

Tablela 1. Opções para ativar o suporte XDMCP para o VNC para diversos servidores XDMCP
Servidor XMDCPNome do arquivo de configuraçãoNome da seçãoOpção
GDM/etc/X11/gdm/custom.conf[xdmcp]enable=true
KDM/usr/share/kde4/config/kdm/kdmrc[Xdmcp]Enable=true
LightDM/etc/lightdm/lightdm.conf[XDMCPServer]enabled=true

É possível localizar a seção XDMCP em seu arquivo de configuração ou ela pode estar totalmente ausente. Se estiver presente, ela pode desativar explicitamente o suporte XMDCP, conter opções comentadas ou estar vazio. Independentemente do estado original do arquivo, você deseja assegurar que a seção XDMCP esteja presente e que esse suporte esteja ativado. Por exemplo, considere uma configuração KDM para ativar o XDMCP:

[Xdmcp]
Enable=true

Algumas distribuições permitem medidas de segurança adicionais que podem precisar ser aliviadas. Uma delas é um firewall. Scripts de firewall tendem a ser específicos à distribuição, portanto, consulte a documentação do sistema para saber como modificar seu firewall. É preciso assegurar que o host local tenha acesso à porta 177 e que seus clientes VNC tenham acesso à porta 5900 (ou a quaisquer outras portas utilizadas para o VNC).

O OpenSUSE usa um arquivo de configuração adicional que controla alguns tipos de acesso, incluindo acesso ao XDMCP: /etc/sysconfig/displaymanager. Abra esse arquivo em um editor de texto e procure a seguinte linha:

DISPLAYMANAGER_REMOTE_ACCESS="no"

Altere esta opção para "sim". Se ela for deixada como "não", o aviso de login do seu servidor XDMCP não estará visível quando se conectar ao servidor VNC. Essa mudança não é necessária na maioria das distribuições: somente o openSUSE usa esse arquivo.

Reiniciando o Servidor XDMCP

Com seu servidor XDMCP configurado para aceitar logins remotos, é preciso reiniciá-lo. Em distribuições que ativam o X por meio de um arquivo de inicialização do SysV, como Debian e Gentoo, é possível passá-lo a reiniciar :

# /etc/init.d/gdm restart

Se seu sistema utilizar o número do nível de execução para iniciar o X, como Fedora e openSUSE, será preciso alternar para um nível de execução no modo de texto (geralmente 3) e, em seguida, voltar para o nível de execução da GUI (geralmente 5):

# telinit 3
# telinit 5

Lembre-se de que qualquer abordagem encerra o X, portanto, certifique-se de que tenha salvado todo o trabalho aberto em sua sessão X antes de prosseguir.


Testando e depurando a configuração

Nesse ponto, deve ser possível efetuar login de um computador remoto usando um cliente VNC. Por exemplo, a maioria das distribuições Linux oferece um comando chamado vncviewer; é possível digitar:

vncviewer remotename

. . . para efetuar login em remotename por meio do VNC. O resultado, quando o VNC estiver configurado e executando corretamente, é semelhante a Figura 4. Caso tenha configurado diversas sessões VNC em portas diferentes, é possível especificar o número da sessão VNC transmitindo-o como parte do nome do host, como em:

vncviewer remotename:3

. . . para efetuar login na sessão 3 (porta 5903).

Figura 4. Quando configurado para executar com o XDMCP, o VNC fornece um prompt de login tradicional do Linux
Quando configurado para executar com o XDMCP, o VNC fornece um prompt de login tradicional do Linux

Caso não seja possível visualizar uma tela de login do XDMCP ao executar esse teste, será preciso realizar uma depuração. O que segue deve ser verificado:

  • Se vncviewer relata que a conexão foi recusada, isso muito provavelmente significa que o super servidor não foi configurado corretamente no computador servidor do VNC. Reveja sua configuração do xinetd e tente reiniciar o super servidor. Também é possível que um firewall esteja bloqueando o acesso ao computador servidor do VNC.
  • Se o cliente VNC for ativado e se conecta ao servidor, mas tudo o que pode ser visto é uma tela cinza com um cursor que pode ser movido, o problema provavelmente está na configuração do servidor XDMCP. Reveja as configurações descritas anteriormente e reative o servidor XDMCP.
  • Como uma técnica de resolução de problemas geral, verifique seus arquivos de log. Pode ser necessário pesquisar todos os arquivos de log em /var/log para referências ao xinetd, seu servidor XDMCP e seu servidor VNC.

Questões de segurança do VNC

O RFB não é um protocolo seguro; a maioria dos clientes e servidores VNC não criptografa seus dados. (O VNC não criptografa suas próprias senhas, mas o método descrito aqui não usa essas senhas.) Seja cuidadoso com o local e modo de implementação do VNC. Caso queira utilizar o VNC em uma rede descoberta, há três opções:

  • Usar uma rede privada virtual (VPN).
  • Criar uma passagem do protocolo sobre SSH.
  • Usar uma variante do VNC que suporta criptografia, como o TigerVNC, que ativa a criptografia de Segurança da Camada de Transporte.

A ativação de logins do VNC, conforme descrito neste artigo, abre pelo menos duas portas (a porta VNC e a XDMCP) para o mundo externo. É recomendável restringir ambas as portas com regras de firewall a fim de minimizar o risco de abuso. Observe que a porta XDMCP (porta UDP 177) só precisa ser aberta para o host local, portanto, sua regra de firewall pode ser bastante restritiva.


Conclusão

Em geral, a vinculação do VNC e do XDMCP é uma técnica útil para permitir logins remotos da GUI em computadores Linux de vários usuários. Esse método tem vantagens sobre o uso do XDMCP diretamente em ambientes de plataforma cruzada ou se a solução de problemas de firewall ou de NAT pode ser um problema. Ele é benéfico em relação às abordagens do VNC diretas mais comuns em computadores multiusuários. Lembre-se de considerar os problemas de segurança caso esse método seja utilizado. Esteja preparado para configurar as regras de firewall para restringir o acesso externo indesejado e utilizar criptografia caso suas transferências atravessem redes não confiáveis.

Recursos

Aprender

Obter produtos e tecnologias

  • O TightVNC é enviado com muitas distribuições; também é possível obtê-lo no site do TightVNC.
  • O TigerVNC é uma bifurcação do TightVNC disponível em algumas distribuições. Ele também pode ser obtido no site do TigerVNC. É notável no sentido de que inclui extensões que suportam conexões criptografadas.
  • RealVNC é uma empresa fundada por alguns dos desenvolvedores originais do VNC. Oferece versões gratuitas e comerciais de sua implementação do VNC.
  • Acesseversão de teste do software IBM (disponível para download ou em DVD) e inove em seu próximo projeto de desenvolvimento de software livre próprio usando o software especialmente para desenvolvedores.

Discutir

Comentários

developerWorks: Conecte-se

Los campos obligatorios están marcados con un asterisco (*).


Precisa de um ID IBM?
Esqueceu seu ID IBM?


Esqueceu sua senha?
Alterar sua senha

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


A primeira vez que você entrar no developerWorks, um perfil é criado para você. Informações no seu perfil (seu nome, país / região, e nome da empresa) é apresentado ao público e vai acompanhar qualquer conteúdo que você postar, a menos que você opte por esconder o nome da empresa. Você pode atualizar sua conta IBM a qualquer momento.

Todas as informações enviadas são seguras.

Elija su nombre para mostrar



Ao se conectar ao developerWorks pela primeira vez, é criado um perfil para você e é necessário selecionar um nome de exibição. O nome de exibição acompanhará o conteúdo que você postar no developerWorks.

Escolha um nome de exibição de 3 - 31 caracteres. Seu nome de exibição deve ser exclusivo na comunidade do developerWorks e não deve ser o seu endereço de email por motivo de privacidade.

Los campos obligatorios están marcados con un asterisco (*).

(Escolha um nome de exibição de 3 - 31 caracteres.)

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


Todas as informações enviadas são seguras.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=Software livre, Linux
ArticleID=813790
ArticleTitle=Ativar Logins de Vários Usuários com o VNC
publish-date=05112012