4.2. SSH: operações seguras de rede

Com cada vez mais computadores instalados em ambientes de rede, sempre torna-se necessário acessar hosts de um local remoto. Isso normalmente significa que um usuário envia strings de login e senha para fins de autenticação. Como essas strings são transmitidas como texto simples, elas podem ser interceptadas e usadas de forma incorreta para obter acesso à conta do usuário sem que o usuário autorizado sequer saiba disso. Além da possibilidade de todos os arquivos do usuário serem abertos por um invasor, a conta ilegal pode ser usada para obter acesso de administrador ou root, ou para penetrar em outros sistemas. Anteriormente, as conexões remotas eram estabelecidas com telnet, que não oferece proteção contra espionagem na forma de criptografia nem de outros mecanismos de segurança. Há outros canais de comunicação sem proteção, como o tradicional protocolo FTP e alguns programas de cópia remotos.

A suíte do SSH fornece a proteção necessária, criptografando as strings de autenticação (normalmente um nome de login e uma senha) e todos os outros dados que sofrem intercâmbio nos hosts. Com o SSH, o fluxo de dados ainda pode ser registrado por terceiros, mas o conteúdo é criptografado e não pode ser revertido em texto simples, a menos que a chave de criptografia seja conhecida. Dessa forma, o SSF permite a comunicação segura em redes desprotegidas, como a Internet. O padrão de SSH que vem com o SUSE Linux é o OpenSSH.

4.2.1. Pacote OpenSSH

O SUSE Linux instala o pacote OpenSSH por padrão. Os programas ssh, scp e sftp são alternativas disponíveis ao telnet, rlogin, rsh, rcp e ftp. Na configuração padrão, o acesso a um sistema SUSE Linux só é possível com os utilitários do OpenSSH e somente se o firewall permitir acesso.

4.2.2. Programa ssh

Usando o programa ssh, é possível fazer login em sistemas remotos e trabalhar de forma interativa. Ele substitui o telnet e o rlogin. O programa slogin é apenas um link simbólico para o ssh. Por exemplo, efetue login no host sun com o comando ssh sun. O host solicita a senha para o sun.

Depois da autenticação bem-sucedida, você pode trabalhar na linha de comando remota ou usar aplicativos interativos, como o YaST. Se o nome de usuário local for diferente do nome de usuário remoto, você poderá efetuar login usando um nome de login diferente, com ssh -l augustine sun ou ssh augustine@sun.

Além disso, o ssh oferece a possibilidade de executar comandos em sistemas remotos, como conhecido no rsh. No exemplo a seguir, execute o comando uptime no host sun e crie um diretório com o nome tmp. A saída do programa será exibida no terminal local do host earth.

ssh otherplanet "uptime; mkdir tmp" 
tux@otherplanet's password:
1:21pm  up  2:17,  9 users,  load average: 0.15, 0.04, 0.02

As aspas são necessárias aqui para enviar as duas instruções com um comando. Somente com esse procedimento o segundo comando é executado no sun.

4.2.3. scp (Secure Copy - Cópia Segura)

O scp copia arquivos em uma máquina remota. Ele é um substituto seguro e criptografado para o rcp. Por exemplo, scp MyLetter.tex sun: copia o arquivo MyLetter.tex do host earth para o host sun. Se o nome de usuário do earth for diferente do nome de usuário do sun, especifique o do sun usando o formato username@host. Não há opção -l para esse comando.

Depois que a senha correta é digitada, o scp inicia a transferência de dados e mostra uma linha crescente de asteriscos para simular uma barra de progresso. Além disso, o programa exibe o tempo estimado de chegada à direita da barra de progresso. Suprima toda a saída fornecendo a opção -q.

O scp também fornece um recurso de cópia recursiva para diretórios inteiros. O comando scp -r src/ sun:backup/ copia todo o conteúdo do diretório src, incluindo todos os subdiretórios, no diretório backup do host sun. Se esse subdiretório ainda não existir, ele será criado automaticamente.

A opção -p avisa ao scp para não mudar a marcação de horário dos arquivos. A opção -C compacta a transferência de dados. Assim o volume de dados a ser transferido é minimizado, embora seja criada uma carga mais pesada para o processador.

4.2.4. sftp (Secure File Transfer - Transferência Segura de Arquivos)

O programa sftp pode ser usado como alternativa ao scp para a transferência segura de arquivos. Durante uma sessão do sftp, você pode usar muitos comandos conhecidos do ftp. O programa sftp pode ser uma alternativa melhor ao scp, especialmente na transferência de dados em que os nomes de arquivos são desconhecidos.

4.2.5. Daemon SSH (sshd) - executado no servidor

Para trabalhar com os programas clientes do SSH ssh e scp, o servidor daemon SSH deve estar em execução em segundo plano, escutando conexões na porta TCP/IP 22. O daemon garante três pares de chaves quando é iniciado pela primeira vez. Cada par de chaves consiste em uma chave privada e uma pública. Portanto, esse procedimento é conhecido como baseado em chave pública. Para garantir a segurança da comunicação via SSH, o acesso a arquivos de chave privada deve ser restrito ao administrador do sistema. As permissões de arquivos são definidas adequadamente pela instalação padrão. As chaves privadas só são exigidas localmente pelo daemon SSH e não devem ser fornecidas a ninguém mais. Os componentes da chave pública (reconhecidos pela extensão de nome .pub) são enviados para o cliente que solicita a conexão. Todos os usuários podem lê-los.

O cliente SSH inicia uma conexão. O daemon SSH e o cliente SSH que solicitou a conexão fazem um intercâmbio de dados de identificação para comparar as versões de software e o protocolo, e para evitar conexões pela porta errada. Como um processo filho do daemon SSH original responde à solicitação, várias conexões de SSH podem ser feitas ao mesmo tempo.

Para a comunicação entre o servidor SSH e o cliente SSH, o OpenSSH suporta as versões 1 e 2 do protocolo SSH. Os sistemas SUSE Linux recentes têm a versão 2 como padrão. Para continuar usando a versão 1 depois de uma atualização, siga as instruções de /usr/share/doc/packages/openssh/README.SuSE. Este documento também descreve como um ambiente SSH 1 pode ser transformado em um ambiente de trabalho SSH 2 em apenas algumas etapas.

Ao usar a versão 1 do SSH, o servidor envia sua chave pública de host e uma chave de servidor, que é gerada novamente pelo daemon SSH a cada hora. Ambas permitem que o cliente SSH criptografe uma chave de sessão escolhida livremente, que é enviada ao servidor SSH. O cliente SSH também comunica ao servidor qual método de criptografia (cifra) deve ser usado.

A versão 2 do protocolo de SSH não requer uma chave de servidor. Os dois lados usam um algoritmo de acordo com Diffie-Helman para fazer o intercâmbio de suas chaves.

O host privado e as chaves do servidor são absolutamente necessários para descriptografar a chave da sessão e não podem ser derivados de partes públicas. Somente o daemon SSH contatado pode descriptografar a chave da sessão usando suas chaves privadas (consulte man /usr/share/doc/packages/openssh/RFC.nroff). Essa fase inicial de conexão pode ser observada de perto, se você ativar a opção de depuração verbosa -v do cliente SSH.

A versão 2 do protocolo SSH é usada por padrão. Substitua-a pela versão 1 do protocolo com o switch -1. O cliente armazena todas as chaves públicas do host no arquivo ~/.ssh/known_hosts depois de seu primeiro contato com um host remoto. Esse procedimento evita ataques man-in-the-middle (MITM) - tentativas de servidores SSH estrangeiros usarem nomes e endereços IP falsos. Esses ataques são detectados por uma chave de host não incluída em ~/.ssh/known_hosts ou pela incapacidade do servidor de descriptografar a chave da sessão na ausência de um correlativo privado apropriado.

É recomendável fazer backup das chaves públicas e privadas armazenadas em /etc/ssh/ em um local externo seguro. Desta forma, as modificações das chaves podem ser detectadas e as chaves antigas podem ser usadas novamente depois de uma reinstalação. Esse procedimento poupa os usuários de avisos de desproteção. Verificou-se que, apesar do aviso - na realidade trata-se do servidor SSH correto -, a entrada para o sistema existente deve ser removida de ~/.ssh/known_hosts.

4.2.6. Mecanismos de autenticação do SSH

Agora é hora da verdadeira autenticação, que, em sua forma mais simples, consiste na digitação de uma senha, conforme mencionado anteriormente. A meta do SSH é apresentar um software seguro que também seja fácil de usar. Como ele deve substituir o rsh e o rlogin, o SSH também deve ser capaz de fornecer um método de autenticação apropriado para uso diário. O SSH consegue isso por meio de outro par de chaves, gerado pelo usuário. O pacote do SSH fornece um programa de auxílio para isso: ssh-keygen. Depois da digitação de ssh-keygen -t rsa ou ssh-keygen -t dsa, o par de chaves é gerado e você deverá informar o nome do arquivo base em que as chaves serão armazenadas.

Confirme a configuração padrão e responda à solicitação de uma frase secreta. Mesmo se o software sugerir que a frase secreta fique em branco, é recomendável inserir um texto de 10 a 30 caracteres para o procedimento descrito aqui. Não use palavras e frases curtas e simples. Confirme a frase secreta repetindo-a. Depois, você verá o local de armazenamento das chaves pública e privada, neste exemplo os arquivos id_rsa e id_rsa.pub.

Use ssh-keygen -p -t rsa ou ssh-keygen -p -t dsa para mudar sua frase secreta antiga. Copie o componente da chave pública (id_rsa.pub, no exemplo) na máquina remota e salve-o como ~/.ssh/authorized_keys. Você será solicitado a autenticar-se com sua frase secreta na próxima vez em que estabelecer uma conexão. Se isso não ocorrer, verifique o local e o conteúdo desses arquivos.

A longo prazo, esse procedimento será mais importuno do que fornecer sempre a senha. Portanto, o pacote do SSH fornece outra ferramenta, o ssh-agent, que mantém as chaves privadas durante uma sessão X. Toda a sessão X é iniciada como um processo-filho do ssh-agent. A forma mais fácil de fazer isso é definir a variável usessh no começo do arquivo .xsession como yes e efetuar login por meio de um gerenciador de vídeo, como o KDM ou o XDM. Como alternativa, digite ssh-agent startx.

Agora você pode usar o ssh ou o scp como de costume. Se tiver distribuído sua chave pública como descrito acima, não será mais solicitado a informar sua senha. Fique atento para concluir a sessão X ou bloqueá-la com um aplicativo de proteção de senha, como o xlock.

Todas as mudanças relevantes resultantes do lançamento da versão 2 do protocolo SSH também estão documentadas no arquivo /usr/share/doc/packages/openssh/README.SuSE.

4.2.7. X, autenticação e mecanismos de encaminhamento

Além das melhorias relativas a segurança descritas anteriormente, o SSH também simplifica o uso dos aplicativos X remotos. Se você executar ssh com a opção -X, a variável DISPLAY será automaticamente definida na máquina remota, e todas as saídas X serão exportadas para a máquina remota pela conexão SSH existente. Ao mesmo tempo, os aplicativos X iniciados remotamente e visualizados localmente com esse método não poderão ser interceptados por pessoas sem autorização.

Com a adição da opção -A, o mecanismo de autenticação ssh-agent passa para a próxima máquina. Dessa forma, você poderá trabalhar em máquinas diferentes sem precisar digitar a senha, mas somente se tiver distribuído sua chave pública nos hosts de destino e a gravado adequadamente neles.

Os dois mecanismos são desativados nas configurações padrão, mas podem ser ativados de forma permanente a qualquer momento no arquivo de configuração de todo o sistema /etc/ssh/sshd_config ou pelo ~/.ssh/config do usuário.

O ssh também pode ser usado para redirecionar conexões TCP/IP. Nos exemplos abaixo, o SSH foi configurado para redirecionar as portas SMTP e POP3, respectivamente.

ssh -L 25:sun:25 earth

Com esse comando, qualquer conexão direcionada para a porta 25 (SMTP) do earth é redirecionada para a porta SMTP do sun por meio de um canal criptografado. Esse recurso é especialmente útil para os que usam servidores SMTP sem os recursos SMTP-AUTH ou POP-before-SMTP. De qualquer local arbitrário conectado a uma rede, é possível transferir e-mails para o servidor de correio eletrônico “doméstico” para entrega. Da mesma forma, todas as solicitações de POP3 (porta 110) do earth podem ser encaminhadas para a porta POP3 do sun com esse comando.

ssh -L 110:sun:110 earth

Os dois comandos devem ser executados como root, pois a conexão é feita para portas locais privilegiadas. Os e-mails são enviados e recuperados por usuários normais em uma conexão SSH existente. Os hosts SMTP e POP3 devem ser definidos como localhost para que isso funcione. Outras informações podem ser encontradas nas páginas de manual referentes a cada programa descrito acima, bem como nos arquivos em /usr/share/doc/packages/openssh.