9.2. Login remoto

É essencial para um(a) administrador(a) ser capaz de se conectar a um computador remotamente. Servidores, confinados em sua própria sala, raramente são equipados com teclados e monitores permanentes — mas estão conectados à rede.

9.2.1. Login remoto seguro: SSH

O protocolo SSH (Secure SHell) foi projetado com segurança e confiabilidade em mente. Conexões usando SSH estão seguras: o parceiro é autenticado e todas as trocas de dados criptografadas.

VOCABULÁRIO Autenticação, criptografia

Quando você precisar dar a um cliente a capacidade de conduzir ou desencadear ações em um servidor, a segurança é importante. Você deve garantir a identidade do cliente; Esta é a autenticação. Essa identidade geralmente consiste de uma senha ou frase-senha que deve ser mantida em segredo, ou qualquer outro cliente pode obtê-la. Este é o propósito da criptografia, que é uma forma de codificação que permite que dois sistemas comuniquem informações confidenciais sobre um canal público, protegendo-as de ser lidas por outros.

Autenticação e criptografia muitas vezes são termos mencionados juntos porque são frequentemente usados em conjunto, e porque geralmente são implementados com conceitos matemáticos semelhantes.

SSH também oferece dois serviços de transferência de arquivo. scp é uma ferramenta de linha de comando que pode ser usada como cp, exceto que qualquer caminho a outra máquina é prefixado com o nome da máquina, seguido por dois-pontos.

$ scp arquivo máquina:/tmp/

sftp é um comando interativo, semelhante ao ftp. Em uma única sessão, o sftp pode transferir vários arquivos, e com ele é possível manipular arquivos remotos (apagar, renomear, alterar permissões, etc.).

O Debian usa o OpenSSH, uma versão livre do SSH mantido pelo projeto OpenBSD (um sistema operacional livre baseado no núcleo BSD, focado em segurança) e uma bifurcação do programa original SSH desenvolvido pela empresa SSH Communications Security Corp, da Finlândia. Esta empresa desenvolveu inicialmente o SSH como software livre, mas num dado momento decidiu continuar o seu desenvolvimento sob uma licença proprietária. O projeto OpenBSD criou então o OpenSSH para manter uma versão gratuita do SSH.

DE VOLTA AO BÁSICO Ramificação (fork)

Uma ramificação (fork), na área de software, significa um novo projeto que se inicia como um clone de um projeto existente e que vai competir com ele. A partir daí, ambos os softwares irão divergir rapidamente em termos de novos desenvolvimentos. Uma ramificação é frequentemente o resultado de divergências dentro da equipe de desenvolvimento.

A opção de ramificar um projeto é um resultado direto da própria natureza do software livre; uma ramificação é um evento saudável quando permite a continuação de um projeto como software livre (por exemplo, em caso de alterações de licença). Uma ramificação decorrente de divergências técnicas ou pessoais é muitas vezes um desperdício de recursos humanos; outra resolução seria preferível. Já se tem notícia de fusões de dois projetos que já passaram por uma divisão anterior.

O OpenSSH é dividido em dois pacotes. A parte do cliente está no pacote openssh-client, e o servidor está no pacote openssh-server. O meta-pacote ssh depende de ambas as partes e facilita a instalação de ambos (apt install ssh), enquanto o pacote task-ssh-server, executado com frequência durante a instalação inicial, depende apenas do pacote servidor.

9.2.1.1. Autenticação Baseada em Chave

Cada vez que alguém se conecta por SSH, o servidor remoto pede uma senha para autenticar o(a) usuário(a). Isso pode ser problemático se você quiser automatizar uma conexão ou se você usar uma ferramenta que requer conexões frequentes com o SSH. Por esse motivo, o SSH oferece um sistema de autenticação baseado em chave.

O(a) usuário(a) gera um par de chaves na máquina cliente com ssh-keygen -t rsa; a chave pública assim gerada é armazenada em ~/.ssh/id_rsa.pub, enquanto a chave privada correspondente é armazenada em ~/.ssh/id_rsa. O(a) usuário(a) pode então usar ssh-copy-id servidor para adicionar sua chave pública ao arquivo ~/.ssh/authorized_keys no servidor, ou, se o acesso SSH ainda não tiver sido ativado, devem solicitar ao(à) administrador(a) que adicione sua chave manualmente.

Se a chave privada não estava protegida por uma "frase-senha" no momento de sua criação, todos os logins subsequentes no servidor vão funcionar sem uma senha. Caso contrário, a chave privada deve ser descriptografada a cada momento digitando-se a senha. Felizmente, ssh-agent nos permite manter as chaves privadas na memória para não ter que digitar novamente com frequência a senha. Para isso, basta usar ssh-add (uma vez por sessão de trabalho), desde que a sessão já esteja associada a uma instância funcional do ssh-agent. O Debian ativa por padrão nas sessões gráficas, mas isso pode ser desativado alterando /etc/X11/Xsession.options e comentando use-ssh-agent. Para uma sessão de console, você pode iniciar o agente manualmente com eval $(ssh-agent).

SEGURANÇA Proteção da chave privada

Quem tem a chave privada pode fazer login na conta assim configurada. É por isso que o acesso para a chave privada é protegido por uma "frase-senha". Alguém que adquire uma cópia de um arquivo de chave privada (por exemplo,~/.ssh/id_rsa) ainda tem de saber esta frase para ser capaz de usá-la. Essa proteção adicional não é, no entanto, impenetrável, e se você acha que esse arquivo foi comprometido, é melhor desativar essa chave nos computadores em que foi instalado (para removê-lo dos arquivos authorized_keys) e substituí-la com uma chave gerada recentemente.

CULTURA Falha do OpenSSL no Debian Etch

A biblioteca OpenSSL, como era inicialmente fornecida no Debian Etch, tinha um grave problema no seu gerador de número aleatório (Random Number Generator - RNG). De fato, o mantenedor Debian tinha feito uma mudança para que aplicações a usando não gerassem avisos quando analisadas por ferramentas de teste de memória como valgrind. Infelizmente, essa mudança também significou que o RNG estava empregando apenas uma fonte de entropia que corresponde ao número do processo (PID), cujos 32.000 possíveis valores não oferecem aleatoriedade suficiente.

→ https://www.debian.org/security/2008/dsa-1571

Especificamente, toda vez que OpenSSL era utilizado para gerar uma chave produzia sempre uma chave dentro de um conjunto conhecido de centenas de milhares de chaves (32.000 multiplicada para um pequeno número de comprimentos de chave). Isso afetou as chaves SSH, chaves SSL e certificados X.509 usados por inúmeras aplicações, tais como OpenVPN. Um(a) cracker só tinha que tentar todas as chaves para ganhar acesso não autorizado. Para reduzir o impacto do problema, o daemon SSH foi modificado para recusar chaves problemáticas listadas nos pacotes openssh-blacklist e openssh-blacklist-extra. Além disso, o comando ssh-vulnkey permite a identificação de chaves possivelmente comprometidas no sistema.

Uma análise mais completa desse incidente mostra que ele é o resultado de múltiplos (pequenos) problemas, tanto dentro do projeto OpenSSL, como com o mantenedor do pacote Debian. Uma biblioteca amplamente utilizada como OpenSSL não deveria - sem modificações - gerar advertências quando testada pelo valgrind. Além disso, o código (especialmente as partes sensíveis como o RNG) deveria ser mais bem comentado para evitar tais erros. Pelo lado do Debian, o mantenedor queria validar as modificações com os desenvolvedores do OpenSSL, mas simplesmente explicou as modificações sem fornecer-lhes o patch correspondente para revisão e falhou em mencionar seu papel dentro do Debian. Finalmente, as escolhas de manutenção não eram ideais: as mudanças feitas no código original não eram documentadas com clareza; todas as modificações eram efetivamente armazenadas em um repositório Subversion, mas acabaram todas agrupadas em um único patch durante a criação do pacote fonte.

Nessas condições, é difícil encontrar as medidas corretivas para evitar que tais incidentes não se repitam. A lição a ser aprendida aqui é que cada divergência que o Debian introduz ao upstream deve ser justificada, documentada, submetida ao upstream quando possível, e amplamente divulgada. É nesta perspectiva que o novo formato de pacote de origem ("3.0 (quilt)") e o serviço web dos fontes Debian foram desenvolvidos.

→ https://sources.debian.org

9.2.1.2. Autenticação Baseada em Certificado

As chaves SSH não podem ser protegidas apenas por uma senha (ou não). Um recurso frequentemente desconhecido é que elas também podem ser assinadas por meio de certificado, tanto as chaves do host quanto as do cliente. Essa abordagem tem várias vantagens. Em vez de manter um arquivo authorized_keys por usuário(a), conforme descrito na seção anterior, o servidor SSH pode ser configurado para confiar em todas as chaves do cliente assinadas pelo mesmo certificado (consulte também Seção 10.2.2, “Infraestrutura de Chaves Públicas: easy-rsa”) usando as diretivas TrustedUserCAKeys e HostCertificate em /etc/ssh/sshd_config.

TrustedUserCAKeys /etc/ssh/ssh_users_ca.pub

HostKey /etc/ssh/ssh_host_ecdsa_key
HostCertificate /etc/ssh/ssh_host_ecdsa_key-cert.pub

Vice-versa, os clientes também podem ser configurados para confiar na chave do hospedeiro assinada pela mesma autoridade, facilitando a manutenção do arquivo known_hosts (mesmo no nível de sistema via /etc/ssh/known_hosts).

@cert-authority *.falcot.com ssh-rsa AAAA[..]

Ambas, chave pública e autenticação de certificado, podem ser usadas lado a lado.

9.2.1.3. Usando aplicações X11 remotamente

O protocolo SSH permite o encaminhamento de dados gráficos (sessão “X11”, a partir do nome do sistema gráfico mais difundido no Unix); o servidor então mantém um canal dedicado para esses dados. Especificamente, um programa gráfico executado remotamente pode ser exibido no servidor X.org da tela local, e toda a sessão (entrada e exibição) será segura. Como essa funcionalidade permite que aplicações remotas interfiram com o sistema local, ela é desabilitada por padrão. Você pode habilitá-la especificando X11Forwarding yes no arquivo de configuração do servidor (/etc/ssh/sshd_config). Finalmente, o(a) usuário(a) também tem que requisitá-la adicionando a opção -X na linha de comando do ssh.

INDO ALÉM Cookies mágicos em .Xauthority

Quando um(a) usuário(a) se conecta via SSH e inicia uma sessão X11 remota, um assim chamado cookie mágico é criado e armazenado no arquivo .Xauthority no diretório inicial do(a) usuário(a) que iniciou a conexão. Esse cookie é usado pelo xauth para autenticar o(a) usuário(a) durante a sessão X. Se o(a) usuário(a) se passar por outro(a) usuário(a) no sistema, por exemplo usando su ou sudo, o cookie não é copiado automaticamente para o(a) usuário(a) de destino e o servidor X se recusará a iniciar aplicativos gráficos no contexto do(a) usuário(a) de destino. Você terá que copiar o cookie mágico no diretório home do(a) usuário(a) de destino (exportando e reimportando o cookie via xauth) para permitir que outro(a) usuário(a) inicie programas gráficos também durante a sessão X.

9.2.1.4. Criando túneis criptografados com encaminhamento de porta

As opções -R e -L permitem ao ssh criar “túneis criptografados” entre duas máquinas, encaminhando com segurança uma porta TCP local (veja barra lateral DE VOLTA AO BÁSICO TCP/UDP) para uma máquina remota ou vice versa.

VOCABULÁRIO Túnel

A Internet, e a maioria das LANs (redes locais) que estão conectadas a ela, operam em modo pacote (packet) e não em modo conectado (connected), o que significa que um pacote emitido de um computador para outro fará paradas em vários roteadores intermediários para encontrar seu destino. Você pode ainda simular uma operação conectada (connected) na qual o fluxo (stream) é encapsulado em pacotes IP normais. Esses pacotes seguem sua rota usual, mas o fluxo é reconstruído sem mudanças até o destino. Chamamos isso de “túnel”, em analogia a uma estrada com túnel na qual veículos vão diretamente da entrada (input) para a saída (output) sem encontrarem nenhum cruzamento, em oposição a um caminho na superfície que envolveria interseções e mudanças de direção.

Pode-se usar essa oportunidade para adicionar criptografia ao túnel: o fluxo (stream) que flui através dele seria então irreconhecível por quem está de fora, mas retornaria sem criptografia na saída do túnel.

ssh -L 8000:server:25 intermediary estabelece uma sessão SSH com a máquina intermediary e escuta pela porta local 8000 (veja Figura 9.3, “Encaminhando uma porta local com SSH”). Para qualquer conexão estabelecida por esta porta, ssh irá iniciar uma conexão a partir do computador intermediary na porta 25 no server, e irá ligar as duas conexões.

ssh -R 8000:server:25 intermediary também estabelece uma sessão SSH com o computador intermediary, mas é nessa máquina que o ssh ouve na porta 8000 (veja Figura 9.4, “Encaminhando uma porta remota com SSH”). Qualquer conexão estabelecida nesta porta fará com que o ssh abra uma conexão a partir da máquina local na porta 25 do server, e faça a ligação das duas conexões.

Nos dois casos, as conexões são feitas pela porta 25 na máquina servidora, que passa pelo túnel SSH estabelecido entre a máquina local e a máquina intermediária. No primeiro caso, a entrada do túnel é a porta local 8000, e os dados se movem em direção à máquina intermediária antes de ser direcionada à servidora na rede “pública”. No segundo caso, a entrada e a saída do túnel são invertidas; a entrada é a porta 8000 na máquina intermediária, a saída é na máquina local, e os dados são então direcionados para a servidora. Na prática, a servidora é usualmente a máquina local ou a intermediária. Dessa forma o SSH mantém segura a conexão de uma ponta a outra.

Figura 9.3. Encaminhando uma porta local com SSH

Figura 9.4. Encaminhando uma porta remota com SSH

9.2.2. Usando ambientes gráficos remotamente

O VNC (Virtual Network Computing - Computação de Rede Virtual) permite o acesso remoto a áreas de trabalho (desktops) gráficas.

Essa ferramenta é, na maioria das vezes, usada para assistência técnica; o(a) administrador(a) pode ver os erros com os quais o(a) usuário(a) está enfrentando, e mostrar-lhes um curso de ação correto, sem estar fisicamente presente.

Primeiro, o(a) usuário(a) tem que autorizar o compartilhamento de sua sessão. O ambiente gráfico GNOME inclui essa opção via Configurações → Compartilhamento (ao contrário de versões anteriores do Debian, onde o(a) usuário(a) tem quem instalar e executar vino). Para que isso funcione, network-manager deve estar gerenciando a rede usada (por exemplo, disponibilizar o modo managed para dispositivos geridos por ifupdown em /etc/NetworkManager/NetworkManager.conf). O KDE Plasma ainda necessita usar o krfb para permitir o compartilhamento de uma sessão existente através do VNC. Para outros ambientes gráficos, os comandos x11vnc ou tightvncserver (dos pacotes Debian de mesmos nomes) ou tigervncserver (tigervnc-standalone-server) servem ao mesmo propósito e fornecem o pacote virtual vnc-server; você pode tornar qualquer um deles disponível para o(a) usuário(a) com uma entrada explícita de menu ou de área de trabalho.

Quando a sessão gráfica se torna disponível através do VNC, o(a) administrador(a) tem que fazer a conexão a ele com o cliente VNC. O GNOME tem os comandos vinagre e remmina para isso, enquanto o projeto KDE provê o comando krdc (no menu em K → Internet → Cliente de Desktop Remoto). Existem outros clientes VNC que usam a linha de comando, como o xtightvncviewer do pacote de mesmo nome ou xtigervncviewer do pacote Debian tigervnc-viewer. Uma vez conectado(a), o(a) administrador(a) pode ver o que está acontecendo, trabalhar na máquina remotamente, e orientar o(a) usuário(a) sobre como proceder.

SEGURANÇA VNC sobre SSH

Se você quiser fazer a conexão pelo VNC e não quiser que seus dados sejam enviados em texto puro pela rede, é possível encapsulá-los em um túnel SSH (veja Seção 9.2.1.4, “Criando túneis criptografados com encaminhamento de porta”). Você simplesmente tem que saber que o VNC usa a porta 5900 por padrão para a primeira tela (chamada “localhost:0”), 5901 para a segunda (chamada “localhost:1”), etc.

O comando ssh -L localhost:5901:localhost:5900 -N -T máquina cria um túnel entre a porta local 5901 na interface localhost e a porta 5900 da máquina. O primeiro “localhost” restringe o SSH a ouvir apenas nesta interface na máquina local. O segundo “localhost” indica a interface na máquina remota que irá receber o tráfego de rede entrando em “localhost:5901”. Assim vncviewer localhost:1 irá conectar o cliente VNC à tela remota, mesmo que você indique o nome da máquina local.

Quando uma sessão VNC for fechada, lembre-se de fechar o túnel por também saindo da sessão SSH correspondente.