É essencial para o administrador ser capaz de se conectar a um computador remotamente. Servidores, confinados em seu quarto, raramente são equipados com permanentes teclados e monitores — mas eles estão conectados à rede.
DE VOLTA AO BÁSICO Cliente, servidor
Um sistema onde vários processos comunicarem é frequentemente descrito com a metáfora de "cliente/servidor". O servidor é o programa que recebe as solicitações provenientes de um cliente e os executa. É o cliente que controla as operações, o servidor não toma qualquer iniciativa própria.
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.
CULTURA Telnet e RSH estão obsoletos
Antes do SSH, Telnet e RSH eram as principais ferramentas usadas para fazer login remotamente. Elas são agora totalmente obsoletas e não devem mais ser usadas, mesmo que o Debian ainda forneça elas.
VOCABULÁRIO Autenticação, criptografia
Quando você precisar dar 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. Esta identidade geralmente consiste de uma senha que deve ser mantida em segredo, ou qualquer outro cliente pode obter a senha. Este é o propósito da criptografia, que é uma forma de codificação que permite que dois sistemas de comunicação de informações confidenciais sobre um canal público, protegendo-o de ser lido por outros.
Autenticação e criptografia, muitas vezes são mencionados juntos, porque eles são freqüentemente usados em conjunto, tanto porque eles 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 kernel 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 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 se 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 pacote do servidor está no openssh-server. O meta-pacote ssh depende de ambas as partes e facilita a instalação de ambos (apt install ssh).
9.2.1.1. Autenticação Baseado em Chave
Cada vez que alguém se conecta por SSH, o servidor remoto pede uma senha para autenticar o usuário. Isto 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 este motivo que o SSH oferece um sistema de autenticação baseado em chave.
O usuário gera um par de chaves na máquina cliente com ssh-keygen -t rsa; a chave pública é armazenada em ~/.ssh/id_rsa.pub,enquanto o chave privada correspondente é armazenada em ~/.ssh/id_rsa.O usuário em seguida usa ssh-copy-id server para adicionar a sua chave pública no servidor ~/.ssh/authorized_keys.Se a chave privada não estava protegida por uma "senha" no momento de sua criação, todos os logins subsequentes sobre o servidor vão funcionar sem uma senha.Caso contrário, a chave privada deve ser decifrada a cada momento digitando a senha.Felizmente, ssh-agent nos permite manter as chaves privadas na memória para não ter que re-digitar com frequencia a senha.Para isso, basta usar ssh-add (uma vez por sessão de trabalho),desde que a sessão já está associado 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.Para uma sessão de console, você pode iniciá-lo 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 é protegida por uma "frase". Alguém que adquire uma cópia de um arquivo de chave privada (por exemplo,~/.ssh/id_rsa) ainda tem de saber esta frasea fim de ser capaz de usá-la. Esta 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 authorized_keys files) e substituia com uma chave recentemente gerada.
CULTURA Falha do OpenSSL no Debian Etch
Especificamente, sempre que OpenSSL era utilizado para gerar uma chave, sempre produzia 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 o OpenVPN. Um 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 que estão 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 deste 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 as 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 elas acabaram todos agrupadas em um único patch durante a criação do pacote fonte.
9.2.1.2. 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 usuário tem que também requisitá-la adicionando a opção -X na linha de comando do ssh.
9.2.1.3. Criando Túneis Criptografados com Encaminhamento de Porta
Suas 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 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 de conectação (connected) aonde o fluxo (stream) é encapsulada em pacotes IP normais. Esses pacotes seguem sua rota usual, mas o fluxo (stream) é rescontruído sem mudanças até o destino. Nós chamamos isso de "túnel", em analogia a uma estrada com túnel aonde 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.
Você pode 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 ao forma sem criptografia na saída do túnel.
ssh -L 8000:server:25 intermediary estabeleceuma 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 abrir uma conexão a partir da máquina local na porta 25 do server, e fazer a ligação das duas conexões.
Nos dois casos, as conexões são feitas pela porta 25 na máquina (host) server, que passa pelo túnel SSH estabelecido entre a máquina local e a máquina intermediary. No primeiro caso, a entrada do túnel é a porta local 8000, e os dados se movem em direção a máquina intermediary antes de ser direcionada ao server 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 intermediary, a saída é na máquina (host) local, e os dados são então direcionados para o server. Na prática, o servidor é 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
O VNC (Virtual Network Computing) permite o acesso remoto ao ambiente de trabalho (desktops) gráfico.
Essa ferramenta é, na maioria das vezes, usada para assistência técnica; o administrador pode ver os erros com os quais o usuário está enfrentando, e mostrar a eles um curso de ação correto, sem estar fisicamente presente.
SEGURANÇA VNC sobre SSH
Se você quer fazer a conexão pelo VNC, e você não quer que seus dados sejam enviados em texto puro pela rede, é possível encapsular os dados através de um túnel SSH (veja Seção 9.2.1.3, "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 (called "localhost:0"), 5901 para a segunda (called "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 "host". 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 a qual irá receber o tráfego de rede entrando em "localhost:5901". Assim vncviewer localhost:1 irá conectar o cliente VNC a tela remota, mesmo que você indique o nome da máquina local.
Quando uma sessão VNC é fechada, lembre-se de fechar o túnel por também saindo da sessão SSH correspondente.
DE VOLTA AO BÁSICOGerenciador de tela
gdm3, kdm, lightdm, and xdm são Gerenciadores de Tela. Eles tomam controle da interface gráfica brevemente depois a inicialização para prover ao usuário uma tela de login. Uma vez que o usuário tenha feito o login, eles executam os programas necessários para iniciar uma sessão gráfica de trabalho.
VNC também funciona para usuários móveis, ou executivos da empresa, os quais ocasionalmente precisam fazer o login a partir de suas casas para acessar um ambiente de trabalho remoto similar ao que eles usam no trabalho. A configuração desse tipo de serviço é mais complicada: você primeiro instala o pacote vnc4server, altera a configuração do gerenciador de tela para aceitar requisições do XDMCP Query (no gdm3, isso pode ser feito adicionando Enable=true na sessão "xdmcp" do /etc/gdm3/daemon.conf), e finalmente, iniciar o servidor VNC com inetd para que a sessão seja iniciada automaticamente quando o usuário tentar fazer o login. Por exemplo, você pode adicionar essa linha ao /etc/inetd.conf:
Redirecionando as conexões de entrada para o gerenciador de tela resolve o problema de autenticação, porque apenas usuários com contas locais irão passar pela tela de login do gdm3 (ou os equivalentes kdm, xdm, etc.). Como essa operação permite múltiplos logins simultâneos sem qualquer problema (sendo o servidor suficientemente poderoso), ele pode ser usado até para fornecer um ambiente de trabalho completo para usuários móveis (ou para menos poderosos sistema de ambiente de trabalho, configurado como 'thin clients'). Os usuários simplesmente fazem o login na tela do servidor com vncviewer server:50, porque a porta usada é a 5950.