Dominando o SSH

Carlos E. Morimoto criou 26/ago/2006

Introduo
Uma vantagem no uso do Linux, apontada por muitos administradores de rede, a
facilidade de administrar o sistema remotamente, tanto via linha de comando (usando o
SSH) quanto com acesso interface grfica (usando o NX Server, o VNC ou o prprio
SSH). Essa uma necessidade bsica para qualquer um que administra diversos
servidores.

Hoje em dia, poucas empresas hospedam seus websites "in house", ou seja, em
servidores instalados dentro da prpria empresa. Quase sempre os servidores ficam
hospedados em datacenters, complexos que oferecem toda a estrutura necessria para
que os servidores fiquem no ar de forma confivel, incluindo links redundantes (se o
link principal cai, existe um segundo de reserva), no-breaks de grande porte, geradores,
refrigerao (a temperatura ambiente mais baixa ajuda os componentes a trabalharem de
forma mais estvel) e assim por diante.

Isso significa que apesar do servidor ser "seu", voc no tem nenhum tipo de acesso
fsico a ele. No pode usar o teclado ou mouse por exemplo, tudo precisa ser feito a
distncia. No Linux, toda a configurao do sistema, instalao de novos programas,
etc. pode ser feita a partir do modo texto, o que permite configurar o servidor e mant-lo
atualizado remotamente, via SSH. Outro ponto interessante que, apesar de ele ser uma
ferramenta nativa do Unix, existem clientes SSH tambm para Windows e outras
plataformas, permitindo que o responsvel administre o servidor mesmo a partir de uma
estao Windows.

Outra possibilidade interessante para o SSH o suporte a distncia. Praticamente tudo

pode ser feito remotamente, desde alteraes na configurao do sistema, instalao de
novos programas ou atualizaes de segurana, at a instalao de um novo kernel
(voc instala, configura o grub e em seguida reinicia a mquina torcendo para que tudo
esteja correto e ela volte depois de dois minutos). possvel at mesmo fazer uma
reinstalao completa do sistema remotamente. Nesse caso, voc instalaria a nova cpia
em uma partio separada, usando um chroot, e configuraria o gerenciador de boot para
inici-la por default depois do reboot.

Outro uso comum, desta vez dentro das redes locais, o uso remoto de aplicativos. Em
muitas situaes faz sentido instalar determinados aplicativos em um servidor central e
abrir sesses remotas nos clientes. Isso permite centralizar as informaes no servidor
(facilitando os backups) e, ao mesmo tempo, usar menos recursos nos clientes,
permitindo o uso de micros mais antigos. O exemplo mais desenvolvido o LTSP, que

1
permite usar micros antigos, de praticamente qualquer configurao, como clientes de
um servidor rpido. Um nico servidor pode atender a 20 ou at mesmo 30 clientes.

Entendendo o SSH

O SSH a minha ferramenta preferida. Ele permite administrar mquinas remotamente

(executando tanto comandos em modo texto quanto aplicativos grficos), permite
transferir arquivos de vrias formas diferentes e, como se no bastasse, permite tambm
encapsular outros protocolos, permitindo, por exemplo, acessar uma sesso do VNC
atravs de um tnel seguro.

A grande vantagem do SSH sobre outras ferramentas de acesso remoto a grande

nfase na segurana. Um servidor SSH bem configurado virtualmente impenetrvel e
voc pode acess-lo de forma segura, mesmo que a sua rede local esteja comprometida.
Ele utiliza um conjunto de tcnicas de criptografia para assegurar que apenas as pessoas
autorizadas tenham acesso ao servidor, que todos os dados transmitidos sejam
impossveis de decifrar e que a integridade da conexo seja mantida.

So previstas respostas para diversos tipos de ataques conhecidos. O SSH detecta casos
em que o servidor tenha sido substitudo por outra mquina, situaes nas quais se tenta
injetar dados na conexo (ou seja, tirar proveito de uma conexo aberta para incluir
pacotes com comandos adicionais) e inclui at mesmo tcnicas de "despiste", que
tornam muito mais complicado descobrir em qual pacote encriptado foi transmitida a
senha de acesso, por exemplo, dificultando a vida de quem pretende descobrir a senha
usando um ataque de fora bruta.

A idia central que, mesmo em situaes onde seja fcil interceptar a transmisso
(como no caso de uma rede wireless pblica), seja impossvel descobrir o contedo dos
pacotes, devido encriptao. possvel ainda, utilizar um par de chaves em vez de
uma senha como forma de autenticao. Nesse caso, alm de possuir a chave privada
(um arquivo que pode ser salvo no HD, em um pendrive ou mesmo em um smartcard),
preciso saber a passphrase, que pode ser uma senha especialmente longa e difcil de
adivinhar.

Voc poderia argumentar que qualquer algoritmo de encriptao pode ser quebrado via
fora bruta (onde simplesmente so testadas todas as possibilidades possveis, at
encontrar a combinao correta), de forma que nenhum sistema de encriptao
inteiramente seguro. Entretanto, ataques de fora bruta s so realmente viveis contra
chaves de 40 ou 64 bits; acima disso invivel, pois a cada bit adicionado, o processo
torna-se exponencialmente mais demorado.

Um exemplo de protocolo pouco seguro o WEP de 64 bits (que na verdade utiliza uma
chave de 40 bits), usado em redes wireless pouco protegidas. Ele pode ser quebrado em
pouco tempo, caso voc consiga capturar um volume considervel de transmisses

2
usando um sniffer (um programa que captura a transmisso da rede, como o Kismet). O
DES, um dos algoritmos mais tradicionais, que usa chaves de 64 bits (reais), pode ser
quebrado em menos de um dia, caso voc tenha acesso a um cluster de 100 mquinas
com processadores Xeon ou Opteron quad-core.

Uma chave de 64 bits cerca de 16 milhes de vezes mais difcil de quebrar via fora
bruta do que uma de 40 bits, como as que eram utilizadas no SSL dos navegadores a at
poucos anos. Uma chave de 128 bits por sua vez, (arredondando)
18.447.000.000.000.000.000 vezes mais demorada de quebrar que uma de 64 bits, de
forma que, uma chave de 64 bits pode ser quebrada caso voc tenha o tempo e os
recursos necessrios disposio, mas uma de 128 (sem brechas conhecidas)
impossvel de quebrar com tecnologia atual.

O perigo no caso dos algoritmos de encriptao no so propriamente os ataques de

fora bruta (que exigem muito tempo e recursos), mas sim falhas que permitam
descobrir a chave usada em menos tempo. As verses originais do WEP (o sistema de
encriptao para redes wireless anterior ao WPA), por exemplo, podiam ser quebradas
rapidamente devido a um conjunto de falhas no algoritmo usado, o que levou os
fabricantes a atualizarem rapidamente todos os seus produtos. Outro exemplo o
sistema usado na encriptao dos DVDs, que quebrado em poucos segundos por uma
mquina atual, utilizando um algoritmo de poucas linhas.

Felizmente, este no o caso dos algoritmos usados no SSH. Por serem abertos,
qualquer falha similar que pudesse eventualmente existir j teria sido descoberta e
corrigida. O SSH usado em tantos servidores importantes que uma brecha grave
poderia (literalmente) parar o mundo. Por isso, todo o cdigo exaustivamente auditado
por uma variedade de empresas e rgos governamentais.

O SSH utiliza chaves assimtricas para fazer a autenticao. As chaves assimtricas so

um sistema muito interessante, onde temos um par de chaves em vez de uma nica
chave simtrica. Uma (a chave pblica), permite apenas encriptar dados, enquanto a
segunda (a chave privada) permite desencriptar as informaes embaralhadas pela
primeira. O grande segredo que qualquer informao embaralhada usando a chave
pblica pode ser recuperada apenas usando a chave privada correspondente. Como o
nome sugere, a chave pblica pode ser distribuda livremente, pois serve apenas para
gerar as mensagens encriptadas, sem permitir l-las posteriormente.

Quando voc se conecta a um servidor SSH, seu micro e o servidor trocam suas
respectivas chaves pblicas, permitindo que um envie informaes para o outro de
forma segura. Atravs deste canal inicial feita a autenticao, seja utilizando login e
senha, seja utilizando chave e passphrase (como veremos a seguir).

At aqui, tudo feito utilizando chaves de 512 bits ou mais (de acordo com a
configurao). O problema que, embora virtualmente impossvel de quebrar, este nvel

3
de encriptao demanda um volume muito grande de processamento. Se todas as
informaes fossem transmitidas desta forma, o SSH seria muito lento.

Para solucionar este problema, depois de fazer a autenticao, o SSH passa a utilizar um
algoritmo mais simples (que demanda muito menos processamento) para transmitir os
dados. Por padro utilizado o 3DES (triple-DES), que utiliza uma combinao de trs
chaves DES, de 64 bits cada. As chaves so trocadas periodicamente durante a conexo,
o que torna o sistema quase impossvel de quebrar. Na configurao do servidor e/ou
cliente, possvel especificar outro algoritmo, como o Blowfish. Isso garante uma boa
relao entre segurana e desempenho.

O SSH dividido em dois mdulos. O sshd o mdulo servidor, um servio que fica
residente na mquina que ser acessada, enquanto ossh o mdulo cliente, um utilitrio
que voc utiliza para acess-lo.

Para instalar o SSH no servidor, basta instalar o pacote "openssh-server" usando o

gerenciador de pacotes, como em:

# apt-get install openssh-server

ou:

# yum install openssh-server

Na maioria dos casos, ao fazer uma instalao em modo servidor do sistema o SSH ser
instalado e configurado para subir no boot automaticamente, mas, de qualquer forma,
no custa verificar. Nas distribuies derivadas do Debian, ele ativado usando o
servio "ssh", como em:

# /etc/init.d/ssh start

Nas derivadas do Red Hat, incluindo o Mandriva e o CentOS o servio se chama sshd:

# service sshd start

No caso do CentOS, voc precisa usar o comando "chkconfig sshd on" para ativar a
inicializao automtica do servio caso o pacote seja instalado depois da instalao do
sistema:

# chkconfig sshd on

Como de praxe, necessrio manter a porta 22 usada pelo SSH aberta no firewall do
servidor. O SSH permite fazer quase tudo atravs dessa nica porta, atendendo a
diversos clientes simultneos.

4
Concluindo, para usar o SSH no seu micro de trabalho necessrio ter instalado apenas
o pacote "openssh-client". Veja que o cliente e o servidor so intencionalmente
mantidos em pacotes separados justamente para permitir que voc instale apenas um ou
outro conforme necessrio.

A configurao do servidor, independentemente da distribuio usada, vai no arquivo

"/etc/ssh/sshd_config", enquanto a configurao do cliente vai no
"/etc/ssh/ssh_config". Note que muda apenas um "d" entre os dois; cuidado para no
confundir car com batata doce. ;)

Outra observao que alm do OpenSSH, que abordo aqui, existem outras verses do
SSH, como o Tectia (uma verso comercial, disponvel no http://ssh.com) e o SunSSH
que, embora conservem diferenas no funcionamento e na configurao, so
compatveis entre si. O SSH , na verdade, um protocolo aberto e no o nome de uma
soluo especfica.

O uso bsico do SSH bastante simples, j que basta usar o comando "ssh
login@servidor" para acessar o servidor remoto e, a partir da, rodar os comandos
desejados. Entretanto, essa apenas a ponta do iceberg. O SSH to rico em funes
que at mesmo os administradores mais experientes raramente usam mais do que um
punhado das funes disponveis. Vamos ento a uma viso mais aprofundada do SSH,
comeando com dicas de configurao:

Configurao do cliente SSH

Ao ser ativado, o padro do servidor SSH permitir acesso usando qualquer
uma das contas de usurio cadastradas no sistema, pedindo apenas a
senha de acesso. Para acessar o servidor "192.168.0.2", usando o login
"morimoto", por exemplo, o comando seria:

$ ssh morimoto@192.168.0.2

Em vez de usar a arroba, voc pode tambm especificar o login usando o parmetro "-l"
(de login), como em:

$ ssh -l morimoto 192.168.0.2

Voc pode tambm acessar o servidor usando o domnio, como em:

$ ssh morimoto@gdhpress.com.br

Caso voc omita o nome do usurio, o SSH presume que voc quer acessar usando o
mesmo login que est utilizando na mquina local. Se voc est logado como "tux", ele
tentar fazer login usando uma conta "tux" no servidor remoto. Naturalmente, s
funciona caso voc use o mesmo login em ambas as mquinas.

Ao acessar micros dentro da rede local, voc pode tambm cham-los pelo nome, como
em "ssh morimoto@servidor". Neste caso, voc precisar primeiro editar o arquivo
5
"/etc/hosts" (no cliente), incluindo os nmeros de IP das mquinas e os nomes
correspondentes. O formato deste arquivo bem simples, basta fornecer o IP e o nome
da mquina correspondente, um por linha, como em:

127.0.0.1 localhost
192.168.0.2 servidor
192.168.0.6 athenas

A configurao do arquivo "/etc/hosts" vale apenas para a sua prpria mquina, ele nada
mais do que um arquivo com aliases. Se voc quiser que os apelidos sejam vlidos
tambm para as demais mquinas da rede, a melhor opo configurar um servidor
DNS de rede local.

Voltando configurao do SSH, vamos a algumas opes importantes dentro da

configurao do cliente SSH, que vo no arquivo "/etc/ssh/ssh_config":

Aplicativos grficos: Alm de oferecer acesso via linha de comando, o SSH permite
rodar aplicativos grficos remotamente (X11 forwarding). Muitas distribuies trazem o
recurso desabilitado por padro. Nestes casos, edite o arquivo "/etc/ssh/ssh_config" (no
cliente) e substitua a linha "ForwardX11 no" por:

ForwardX11 yes

Outra opo adicionar o parmetro "-X" ao se conectar, como em "ssh -X

tux@192.168.0.1". A partir da, voc pode chamar os aplicativos grficos normalmente,
como se estivesse usando um terminal local.

O maior problema com o uso de aplicativos grficos via SSH que ele s funciona
satisfatoriamente dentro da rede local. Via Internet os aplicativos grficos ficam
realmente muito lentos (mesmo em uma conexo de 4 ou 8 megabits), pois o protocolo
do X otimizado para uso local, com uso intensivo de pacotes de retorno e sem nenhum
tipo de cache. Isso faz com que muitos administradores desabilitem o X11 forwarding
no prprio servidor.

Para rodar aplicativos grficos de forma segura via Internet, a melhor soluo usar o
NX Server (que veremos em detalhes mais adiante). Ele um sistema de acesso remoto
baseado no SSH, que utiliza um protocolo bastante otimizado. Nele voc tem um
desktop completo (similar ao VNC), mas com um desempenho muito superior, mesmo
em conexes via modem.

Compresso: No caso de servidores acessveis via Internet, voc pode reduzir um

pouco o consumo de banda ativando a compresso de dados via gzip, o que feito
adicionado a linha:

6
Compression = yes

Voc pode tambm ativar a compresso adicionando a opo "-C" na hora de se

conectar. Quase todas as opes do cliente SSH podem ser especificadas tanto no
arquivo, quanto via linha de comando.

Keep Alive: Outro problema comum relacionado ao SSH a conexo ser fechada pelo
servidor depois de alguns minutos de inatividade. Em muitas situaes voc quer
manter a conexo aberta por longos perodos, sem precisar ficar dando um "ls" ou um
"pwd" a cada dois minutos para manter a conexo aberta.

Voc pode evitar o problema fazendo com que o prprio cliente mande pacotes
periodicamente a fim de manter a conexo aberta. Para ativar o recurso, adicione a
opo "ServerAliveInterval" no arquivo, especificando o intervalo entre o envio dos
pacotes (em segundos):

ServerAliveInterval 120

Este um exemplo de arquivo "/etc/ssh/ssh_config", configurado com as opes que

vimos at aqui (excluindo os comentrios):

ForwardX11 yes
Compression = yes
Port 22
ServerAliveInterval 120

Como em outros arquivos de configurao, voc no precisa se preocupar em incluir

cada uma das opes disponveis, pois o SSH simplesmente usa os valores default para
as opes no includas no arquivo. Com isso, voc precisa se preocupar apenas com as
opes que conhece, omitindo as demais.

Verificao do servidor: Como parte das verificaes de segurana, o SSH utiliza

tambm um sistema baseado em chaves assimtricas para verificar a identidade do
servidor. O servidor possui uma chave pblica, que enviada ao cliente na primeira
conexo. As identificaes de todos os servidores conhecidos ficam armazenadas no
arquivo ".ssh/known_hosts", dentro do seu diretrio home. Sempre que voc se conecta
da em diante, o cliente SSH envia um "desafio" ao servidor, uma frase encriptada
usando a chave pblica (do servidor), que s pode ser descoberta usando a chave
privada.

7
Isso previne um tipo de ataque muito comum chamado "man in the middle" (que
poderia ser traduzido para "intermedirio", ou "impostor"), em que algum
simplesmente substitui o servidor por outra mquina, usando o mesmo IP, ou sabota o
servidor DNS da rede (ou do provedor de acesso) de forma que ele entregue um IP
forjado quando voc tenta acessar seu servidor baseado no domnio.

O servidor falso pode ser configurado para gravar sua senha e responder com uma
mensagem do tipo "O servidor est em manuteno, tente novamente daqui a algumas
horas". Dessa forma, ele vai ter no apenas acesso sua senha, mas tempo de us-la
para acessar o servidor verdadeiro sem que voc desconfie. Entretanto, isso previsto
dentro do design do SSH; ele percebe que a identificao do servidor mudou e lhe avisa
do problema:

Para continuar preciso que voc remova a linha com a identificao do servidor salva
no arquivo .ssh/know_hosts, dentro do diretrio home do usurio que est utilizando.
Isso pode ser feito de duas formas.

A primeira remover a chave usando o comando "ssh-keygen -R", seguido pelo

endereo IP ou o domnio do servidor (o mesmo que voc especifica ao se conectar a
ele), como em:

# ssh-keygen -R 192.168.1.200

/home/gdhn/.ssh/known_hosts updated.
Original contents retained as /home/gdhn/.ssh/known_hosts.old

Como pode ver, o comando substituiu a edio manual do arquivo, removendo a linha
correspondente ao servidor e salvando um backup do arquivo original por precauo.

A segunda opo editar diretamente o arquivo ".ssh/known_hosts", comentando ou

removendo a linha referente ao servidor (deixando as demais). Dentro do arquivo, voc
ver uma longa linha para cada servidor acessado, comeando com o endereo IP ou o
nome de domnio usado no acesso.

8
Em qualquer um dos dois casos, da prxima vez que tentar se conectar, o SSH exibe
uma mensagem mais simptica, perguntando se voc quer adicionar a nova chave:

The authenticity of host '192.168.1.200 (192.168.1.200)' can't be

established.
RSA key fingerprint is f1:0f:ae:c6:01:d3:23:37:34:e9:29:20:f2:74:a4:2a.
Are you sure you want to continue connecting (yes/no)?

No existe forma de fazer com que o cliente SSH adicione as novas chaves
automaticamente, isso seria uma brecha de segurana. sempre preciso primeiro
remover a chave antiga manualmente.

As chaves de identificao so geradas durante a instalao do SSH e salvas nos

arquivos "/etc/ssh/ssh_host_rsa_key" e "/etc/ssh/ssh_host_dsa_key" (no servidor).
Para no disparar o alarme nos clientes quando precisar reinstalar o sistema no servidor,
ou quando substitu-lo por outra mquina, salve os dois arquivos em um pendrive e
restaure-os depois da instalao. Voc pode fazer isso mesmo ao migrar para outra
distribuio, pois as localizaes dos dois arquivos no mudam.

Uma ltima opo seria desabilitar a checagem das chaves, adicionando a opo
"StrictHostKeyChecking no" na configurao dos clientes. Contudo, isso no
recomendvel, pois desabilita completamente a checagem, abrindo brechas para
ataques.

Configurao do servidor SSH

Voc pode configurar vrias opes relacionadas ao servidor SSH, incluindo a porta
TCP a ser usada editando o arquivo "/etc/ssh/sshd_config". Assim como no caso da
configurao do cliente, a maior parte das opes dentro do arquivo podem ser omitidas
(pois o servidor simplesmente utiliza valores default para as opes que no constarem
no arquivo), mas, de qualquer forma, saudvel especificar todas as opes que
conhece: alm de evitar enganos, uma forma de praticar e memorizar as opes.

Porta: Uma das primeiras linhas a:

Port 22

Esta a porta que ser usada pelo servidor SSH. O padro usar a porta 22. Ao mudar a
porta do servidor aqui, voc dever usar a opo "-p" ao conectar a partir dos clientes
para indicar a porta usada, como em:

# ssh -p 2222 morimoto@gdhn.com.br

9
Outra opo editar o arquivo "/etc/ssh/ssh_config" (nos clientes) e alterar a porta
padro usada por eles. Mudar a porta padro do SSH uma boa idia se voc est
preocupado com a segurana. Muitos dos ataques "casuais" (quando o atacante
simplesmente varre faixas inteiras de endereos, sem um alvo definido), comeam com
um portscan genrico, onde feita uma varredura em faixas inteiras de endereos IP,
procurando por servidores com portas conhecidas abertas, como a 21, a 22 e a 80. Isso
torna o teste mais rpido, permitindo localizar rapidamente um grande volume de hosts
com portas abertas. A partir da, os ataques vo sendo refinados e direcionados apenas
para os servidores vulnerveis encontrados na primeira varredura. Colocar seu servidor
para escutar uma porta mais escondida, algo improvvel como a porta 32456 ou a 54232
reduz sua exposio.

Controle de acesso: Logo abaixo vem a opo "ListenAddress", que permite limitar o
SSH a uma nica interface de rede (mesmo sem usar firewall), til em casos de micros
com duas ou mais placas; o tpico caso em que voc quer que o SSH fique acessvel
apenas na rede local, mas no na Internet, por exemplo. Digamos que o servidor use o
endereo "192.168.0.1" na rede local e voc queira que o servidor SSH no fique
disponvel na Internet. Voc adicionaria a linha:

ListenAddress 192.168.0.1

Note que especificamos nesta opo o prprio IP do servidor na interface escolhida, no

a faixa de IP's da rede local ou os endereos que tero acesso a ele.

Protocolo: Atualmente utilizamos o SSH 2, mas ainda existem alguns poucos clientes
que utilizam a primeira verso do protocolo. Por padro, o servidor SSH aceita
conexes de clientes que utilizam qualquer um dos dois protocolos, o que indicado na
linha:

Protocol 2,1

O protocolo SSH 1 tem alguns problemas fundamentais de segurana, por isso

recomendvel desativar a compatibilidade com ele, aceitando apenas clientes que usam
o SSH 2. Neste caso, a linha fica apenas:

Protocol 2

Restringir a verso do protocolo ajuda a melhorar a segurana, pois evita que usurios
utilizando clientes SSH antigos abram brechas para ataques. Existem, por exemplo,
muitos clientes SSH para uso em celulares que suportam apenas o SSH 1 e utilizam
algoritmos fracos de encriptao. Desativando a compatibilidade com o SSH 1 voc
corta o mal pela raiz.

Usurios e senhas: Outra opo interessante, geralmente colocada logo abaixo, a:

PermitRootLogin yes

10
Esta opo determina se o servidor aceitar que usurios se loguem como root. Do
ponto de vista da segurana, melhor deixar esta opo como "no", pois assim o
usurio precisar primeiro se logar usando um login normal e rodar comandos como
root usando o "sudo" ou "su -":

PermitRootLogin no

Dessa forma, preciso saber duas senhas, ao invs de saber apenas a senha do root,
eliminando a possibilidade de algum atacante obstinado conseguir adivinhar a senha de
root e, assim, obter acesso ao servidor.

Por padro, o SSH permite que qualquer usurio cadastrado no sistema se logue
remotamente, mas voc pode refinar isso atravs da opo "AllowUsers", que especifica
uma lista de usurios que podem usar o SSH. Quem no estiver na lista, continua
usando o sistema localmente, mas no consegue se logar via SSH. Isso evita que contas
com senhas fracas, usadas por usurios que no tm necessidade de acessar o servidor
remotamente coloquem a segurana do sistema em risco. Para permitir que apenas os
usurios "joao" e "maria" possam usar o SSH, por exemplo, adicione a linha:

AllowUsers joao maria

Voc pode ainda inverter a lgica, usando a opo "DenyUsers". Neste caso, todos os
usurios cadastrados no sistema podem fazer login, com exceo dos especificados na
linha, como em:

DenyUsers ricardo manuel

Outra opo relacionada segurana a:

PermitEmptyPasswords no

Esta opo faz com que qualquer conta sem senha fique automaticamente desativada no
SSH, evitando que algum consiga se conectar ao servidor "por acaso" ao descobrir a
conta desprotegida. Lembre-se de que a senha justamente o ponto fraco do SSH. De
nada adianta usar 2048 bits de encriptao se o usurio escreve a senha em um post-it
colado no monitor, ou deixa a senha em branco.

Banner: Alguns servidores exibem mensagens de advertncia antes do prompt de login,

avisando que todas as tentativas de acesso esto sendo monitoradas ou coisas do gnero.
A mensagem especificada atravs da opo "Banner", onde voc indica um arquivo de
texto com o contedo a ser mostrado, como em:

Banner = /etc/ssh/banner.txt

11
X11 Forwarding: Alm de ser usada na configurao dos clientes, a opo
"X11Forwarding" pode ser tambm includa na configurao do servidor:

X11Forwarding yes

Ela determina se o servidor permitir que os clientes executem aplicativos grficos

remotamente. Se o servidor for acessado via Internet ou se possui um link lento, voc
pode deixar esta opo como "no" para economizar banda. Desta forma, os clientes
podero executar apenas comandos e aplicativos de modo texto. Note que ao usar
"X11Forwarding no" o encaminhamento recusado pelo prprio servidor, de forma que
o usurio no consegue rodar aplicativos grficos mesmo que a opo esteja ativa na
configurao do cliente.

- SFTP: O SSH inclui um mdulo de transferncia de arquivos (o SFTP), que veremos

em detalhes a seguir. Ele ativado atravs da linha:

Subsystem sftp /usr/lib/sftp-server

realmente necessrio que esta linha esteja presente para que o SFTP funcione.
Comente esta linha apenas se voc realmente deseja desativ-lo.

Usando chaves de autenticao

Por mais seguras que sejam suas senhas, sempre existe uma pequena possibilidade de
que um atacante descubra alguma delas, observando enquanto voc digita no teclado, ou
que simplesmente consiga adivinh-la a partir de informaes pessoais ou de senhas
antigas. Se voc tem o hbito de usar as mesmas senhas em vrios locais, a
possibilidade cresce, pois muitos servios armazenam ou transmitem senhas de formas
no seguras. Com isso, as senhas acabam sendo o ponto fraco da segurana.

Como de praxe, o SSH oferece uma resposta para o problema. Em vez de depender
unicamente da senha como forma de autenticao, voc pode utilizar um par de chaves
de autenticao, onde a chave pblica instalada nos servidores que sero acessados e a
chave privada (que nunca sai da sua mquina) protegida por uma passphrase, sem a
qual a chave se torna intil.

Nesse caso, temos uma segurana de dois nveis, em que preciso saber a passphrase e,
alm dela, ter a chave privada, um arquivo salvo no HD ou em um pendrive, algo
similar ao sistema bancrio, onde voc precisa ter o carto e saber a senha.

Para gerar o par de chaves, use (no cliente) o comando:

$ ssh-keygen -t rsa

12
Ele deve ser executado usando seu login de usurio (o mesmo que voc usa para acessar
os servidores remotos), no como root:

Generating public/private rsa key pair.

Enter file in which to save the key (/home/morimoto/.ssh/id_rsa):
Created directory '/home/morimoto/.ssh'.
Enter passphrase (empty for no passphrase): ********
Enter same passphrase again: ********
Your identification has been saved in /home/morimoto/.ssh/id_rsa.
Your public key has been saved in /home/morimoto/.ssh/id_rsa.pub.
The key fingerprint is:
ff:28:26:f6:87:67:9f:4c:9a:c8:0a:3b:21:81:88:b4 morimoto@athenas

A passphrase pode ser desde uma senha "normal", com 8 ou 12 caracteres,

at uma frase complexa, sem limite de tamanho; o importante que no
seja algo fcil de adivinhar. A passphrase , na verdade, um componente da
chave de encriptao; sem ela impossvel usar a chave.

O comando gerar os arquivos ".ssh/id_rsa" e ".ssh/id_rsa.pub" dentro do seu diretrio

home, que so, respectivamente, sua chave privada e sua chave pblica. O ".ssh/id_rsa"
um arquivo secreto, que deve usar obrigatoriamente o modo de acesso "600" (que
voc define usando o chmod), para evitar que outros usurios da mquina possam l-lo.
Muitos servidores recusam a conexo caso os arquivos estejam com as permisses
abertas.

Depois de gerar seu par de chaves, falta o comando final, que instala a chave pblica no
servidor, permitindo que ela seja usada para autenticao:

$ ssh-copy-id -i ~/.ssh/id_rsa.pub login@servidor

Como o nome sugere, o comando "ssh-copy-id" copia sua chave pblica, instalando-a
no servidor. Ao us-lo, substitua o "login" pelo seu login de usurio e o "servidor" pelo
endereo IP ou o domnio do servidor.

Ao ser executado, ele abrir uma conexo via SFTP (ainda utilizando seu login e senha
de acesso), que usada para instalar a chave pblica (o arquivo ".ssh/id_rsa.pub",
dentro do seu home) no diretrio correspondente do servidor. Naturalmente, para que a
transferncia funcione, necessrio que o SFTP esteja ativo na configurao do
servidor.

Caso voc utilize o mesmo login de usurio nas duas mquinas (usa o usurio "joao" em
ambas, por exemplo), pode omitir o login no comando, digitando apenas "ssh-copy-id
servidor", como em:

$ ssh-copy-id -i ~/.ssh/id_rsa.pub 192.168.0.1

13
A partir da, ao invs de pedir sua senha, o servidor envia um "desafio" encriptado
usando a chave pblica. Para respond-lo, o cliente SSH na sua mquina precisa usar a
chave privada, que por sua vez precisa ser destravada usando a passphrase. Mesmo que
algum consiga roubar sua chave privada, no conseguir conectar sem saber a
passphrase e vice-versa.

Em resumo, o que o ssh-copy-id faz nada mais do que copiar o contedo do arquivo
".ssh/id_rsa.pub", dentro do seu diretrio home, para o arquivo
".ssh/authorized_keys" dentro do diretrio home do servidor remoto, uma operao
que tambm pode ser realizada manualmente em caso de problemas.

O arquivo ".ssh/id_rsa.pub" composto por uma nica (e longa) linha, que contm sua
chave pblica de encriptao. Ela segue este padro:

ssh-rsa AAAA(muitos caracteres)6lYzxBpu6M3Moe4HXaTs=

login@nomedamaquina"

Voc pode instalar a chave manualmente simplesmente logando-se na mquina remota

via SSH e copiando a linha para dentro do arquivo ".ssh/authorized_keys", o que pode
ser feito copiando e colando o texto atravs de qualquer editor que suporte esta funo,
como o joe ou o vi. No final, o arquivo ".ssh/authorized_keys" da mquina remota
(dentro do home) ter o mesmo contedo do arquivo ".ssh/id_rsa.pub" da sua mquina,
o que orienta o servidor remoto a passar a checar sua chave privada e a passphrase, ao
invs de pedir senha.

Concluindo, depois de gerar a chave e conseguir se conectar atravs dela, voc pode
desativar a possibilidade de fazer logins normais, usando senha. Nesse caso, apenas
voc, que possui a chave gerada, conseguir se conectar ao servidor.

Outras pessoas, mesmo que descubram a senha de alguma das contas, no tero como se
conectar e nem como instalar uma nova chave para faz-lo, a menos que tenham acesso
fsico ao servidor, a fim de copiar a chave manualmente. Isso significa que, mesmo
algum com a senha de root do seu servidor em mos no conseguir fazer nada
remotamente (o sonho de todo administrador ;). Isso pode ser usado para incrementar a
segurana.

Para isso, mude as opes "PasswordAuthentication" e "UsePAM" para "no" no arquivo

"/etc/ssh/sshd_config" do servidor:

PasswordAuthentication no
UsePAM no

14
A opo "PasswordAutentication no" permite desativar o uso das senhas, como
esperado, enquanto a "UsePAM no" refora a configurao, desativando qualquer outra
forma de autenticao com exceo das chaves.

Para que as alteraes entrem em vigor, reinicie o servidor SSH:

# /etc/init.d/ssh restart

ou:

# service sshd restart

SSH com login automtico

Se voc abre conexes SSH com freqncia, sempre com as mesmas mquinas, j deve
estar cansado de ter que ficar digitando seu password ou sua passphrase a cada nova
conexo. A boa notcia que ao usar um par de chaves voc pode automatizar o login de
duas formas diferentes.

A primeira opo, menos segura, simplesmente deixar a passphrase em branco na hora

de gerar as chaves, o que faz com que o login passe a ser automtico. Isso torna as
coisas muito prticas, pois voc pode escrever at mesmo scripts para copiar arquivos
via SFTP, sem precisar se preocupar com senhas.

Esta opo muito usada para criar scripts de backup automtico, capazes de acessar o
servidor e transferir os arquivos de forma automtica, sem que o administrador precise
ficar na frente do terminal para digitar a passphrase, mas no necessariamente uma
boa idia para uso em estaes de trabalho, pois algum que consiga copiar sua chave
privada poderia ganhar acesso irrestrito ao servidor.

Isso no algo to corriqueiro quanto pode parecer, pois a chave privada nunca sai do
seu micro. Para roubar sua chave privada, seria necessrio que algum efetivamente
invadisse o sistema, ou tivesse acesso fsico ao seu micro (para dar boot com o live-CD
e copiar o arquivo para um pendrive), mas, de qualquer forma, no bom dar sopa para
o azar.

Chegamos ento segunda opo, que consiste em usar o ssh-agent para salvar as
passphrases na memria, sem com isso abrir mo da segurana. Ele funciona como uma
espcie de "cache", onde voc digita a passphrase apenas uma vez e ela fica gravada na
memria at que a sesso seja encerrada. A segurana no prejudicada, pois a
passphrase no salva em lugar algum; fica apenas armazenada (de forma encriptada)
em uma rea protegida de memria, acessvel apenas ao ssh-agent. Ao desligar o micro,
tudo perdido.

Para usar o ssh-agent, abra um terminal e use os comandos:

15
$ ssh-agent
$ ssh-add

Ele vai solicitar sua passphrase, como neste exemplo:

Enter passphrase for /home/morimoto/.ssh/id_rsa: ********

Identity added: /home/morimoto/.ssh/id_rsa (/home/morimoto/.ssh/id_rsa)

A partir da, ela fica carregada na memria e voc no precisa mais se preocupar at o
prximo reboot.

No KDE, uma forma prtica de fazer com que os dois comandos sejam executados
automaticamente durante a abertura do sistema, adicion-los em um atalho dentro da
pasta ".kde/Autostart" (dentro do seu diretrio home) de forma que eles sejam
executados automaticamente e voc tenha apenas o trabalho de digitar a chave e dar
Enter. No caso das distribuies baseadas no Gnome, use a opo "Sistema >
Preferncias > Sesses" para adicionar um atalho executando o comando "xterm -e 'ssh-
agent; ssh-add'", obtendo assim o mesmo resultado:

Note que os comandos no devem ser adicionados no "/etc/rc.local" ou outro arquivo de

inicializao, pois precisamos que os comandos sejam executados dentro do seu login
de usurio e no pelo root.

16
Usando o ForwardAgent

Ao usar o ssh-agent para guardar suas passphrases, voc pode ativar a opo
ForwardAgent (no cliente) para permitir que o agente disponvel na sua mquina possa
ser usado para abrir novas sesses SSH quando estiver logado em outras mquinas.

Imagine que voc administra dois servidores remotos: servidor A e servidor B. Voc
instalou a sua chave pblica em ambos e armazenou sua passphrase no ssh-agent, de
forma que voc pode logar em ambos a partir da sua mquina, sem digitar senha.
Porm, se voc estiver logado no servidor A, e precisar copiar um arquivo via sftp para
o servidor B, voc precisaria fornecer a senha ou passphrase, j que o servidor A no
tem acesso sua chave privada, que est no seu micro.

O ForwardAgent resolve isso, permitindo que a partir da sesso aberta no servidor A,

voc possa se conectar no servidor B diretamente, sem precisar fornecer nem a senha
nem a passphrase. Isso feito de forma segura, criando um tnel temporrio,
diretamente entre a sua mquina e o servidor B, fazendo a verificao da chave atravs
dele, sem passar pelo servidor A. Desta forma, no existe a possibilidade de um keytrap,
ou qualquer armadilha instalada no servidor A, ser usada para capturar sua chave ou sua
passphrase. Veja s:

$ ssh gdhn.com.br

morimoto@gdhn:~$ sftp gdhpress.com.br

Connecting to gdhpress.com.br...
sftp>

Nesse exemplo, me conectei ao servidor "gdhn.com.br" e, a partir dele, abri uma

conexo via sftp com o "gdhpress.com.br", que poderia utilizar para transferir arquivos
diretamente entre os dois. Veja, que graas ao trabalho do ForwardAgent, a segunda
conexo foi aberta diretamente, sem que precisasse digitar nenhuma informao
adicional.

Para ativar este recurso, abra o arquivo "/etc/ssh/ssh_config" (na sua mquina, ou seja,
no cliente) e adicione a opo:

ForwardAgent yes

Usando mltiplas chaves

At aqui, aprendemos como utilizar um nico par de chaves. Nada impede que voc
utilize a mesma chave para todos os servidores que administra; na verdade, justamente
isso que a maioria dos administradores faz. Entretanto, isso abre uma pequena
possibilidade de que algum realmente consiga copiar o arquivo com sua chave privada
(acessando seu micro enquanto estiver fora do escritrio, por exemplo) e que, de alguma

17
forma, consiga descobrir tambm sua passphrase (observando enquanto voc a digita no
teclado, por exemplo), obtendo assim acesso a todos os servidores de uma s vez.

Devido a isso, alguns administradores mais precavidos preferem utilizar diversos pares
de chaves (um para cada servidor), cada um com uma passphrase diferente. Isso oferece
uma barreira de segurana adicional, evitando colocar todos os ovos dentro do mesmo
cesto, mas, por outro lado, torna o processo bem mais trabalhoso.

Para gerar novas chaves, rode o comando "ssh-keygen -t rsa", prestando ateno para
informar um nome de arquivo alternativo na hora que ele pergunta:

Enter file in which to save the key (/home/morimoto/.ssh/id_rsa):

Com isso, voc pode gerar quantos pares de chaves quiser, salvando-os em arquivos
diferentes. A partir da, voc pode escolher qual instalar ao executar o "ssh-copy-id".
Basta especificar o arquivo referente chave pblica que deseja instalar, como em:

$ ssh-copy-id -i ~/.ssh/id_rsa-12.pub login@servidor

Na hora de adicionar a segunda chave no ssh-agent, voc deve tambm especificar a

chave cuja passphrase deve ser carregada na memria, como em:

$ ssh-agent
$ ssh-add ~/.ssh/id_rsa-12

Ao usar vrias chaves, voc precisa executar o ssh-add uma vez para cada chave que
precisar utilizar, a cada boot (imagine o caso de um administrador que administre 20
servidores e use 20 chaves diferentes, por exemplo :). Como disse, usar vrias chaves
aumenta um pouco a segurana, mas torna a administrao bem mais cansativa.

Transferindo arquivos via SFTP

O SSH um verdadeiro canivete suo. Alm de permitir rodar aplicativos e fazer toda a
administrao de um servidor remotamente, ele tambm pode ser usado para transferir
arquivos. A forma mais bsica de fazer isso usar o sftp, um pequeno utilitrio que faz
parte do pacote padro.

Ele oferece uma interface similar dos antigos programas de FTP de modo texto, mas
todos os arquivos transferidos atravs dele trafegam atravs de um tnel encriptado,
criado atravs do SSH. Na prtica, temos uma espcie de VPN temporria, criada no
momento em que efetuada a conexo. A melhor parte que o prprio SSH cuida de
tudo, no necessrio instalar nenhum programa adicional.

18
Para se conectar a um servidor usando o sftp, o comando :

$ sftp usuario@servidor

Se o servidor ssh na outra ponta estiver configurado para escutar em uma porta diferente
da 22, preciso indicar a porta no comando, incluindo o parmetro "-o port=", como
em:

$ sftp -o port=2222 morimoto@gdhpress.com.br

A partir da, voc tem o prompt do sftp. Use o comando "put" para dar upload de um
arquivo e "get" para baixar um arquivo do servidor para a pasta local. Para navegar
entre as pastas do servidor, use os comandos "cd pasta/" (para acessar a pasta), "cd .."
(para subir um diretrio), "ls" (para listar os arquivos) e "pwd" (para ver em qual
diretrio est). Veja um exemplo:

morimoto@athenas:~$ sftp -o port=2222 morimoto@gdhpress.com.br

Connecting to gdhpress.com.br...
Password: ********

sftp> ls
gdhpress.tar.gz www

sftp> get gdhpress.tar.gz

Fetching /home/morimoto/gdhpress.tar.gz togdhpress.tar.gz
/home/morimoto/gdhpress.tar.gz 100% 523MB 945.1KB/s 09:13

sftp> put backupdb.gz

Uploading backupdb.gz to /home/morimoto/ backupdb.gz
backupdb.gz 100% 98MB 967KB/s 01:43

sftp> pwd
Remote working directory: /home/morimoto

Voc pode estar se perguntando como consegui taxas de transferncia de quase 1 MB/s
tanto para download quanto para upload. O segredo aqui que no estou transferindo os
arquivos de um servidor remoto para meu micro de trabalho, mas sim transferindo
diretamente entre dois servidores remotos, onde me loguei no primeiro via SSH e abri a
conexo com o segundo a partir dele. Se os dois servidores esto ligados a portas de 10
megabits e existir uma boa conectividade entre eles, taxas de at 1 MB/s so
perfeitamente normais. Se voc pagar um pouco a mais para ter portas de 100 megabits,
ento possvel conseguir taxas 10 vezes maiores. :)

Voltando ao sftp, existem ainda os comandos "lcd" (local cd), "lls" (local ls), "lmkdir"
(local mkdir) e "lpwd" (local pwd), que permitem mudar o diretrio local. Digamos, por

19
exemplo, que voc est atualmente no diretrio "/mnt/arquivos". Ao abrir a conexo via
sftp, tudo que voc baixar ser colocado automaticamente neste diretrio. Mas, digamos
que voc queira baixar um determinado arquivo para o diretrio "/home/joao". Voc
usaria, ento, o comando "lcd /home/joao" para mudar o diretrio local e depois o "get
arquivo" para baix-lo j na pasta correta. Na hora de dar upload de um arquivo a
mesma coisa. Voc pode usar o "lls" para listar os arquivos no diretrio local e depois o
"put arquivo" para dar upload.

Naturalmente, existem meios mais prticos de transferir os arquivos, usando programas

grficos que suportam o sftp. O dois mais usados so o prprio Konqueror (no KDE) e o
Nautilus (no Gnome), que alm de serem gerenciadores de arquivos, suportam o uso de
diversos protocolos de transferncia, incluindo o sftp.

No Konqueror, digite "fish://", seguido pelo login e o endereo do servidor (separados

por uma arroba) na barra de endereos, como em "fish://gdh@gdhn.com.br". Ele exibe
uma janela grfica pedindo a confirmao da identidade do servidor (apenas na primeira
conexo) e em seguida outra, solicitando a senha. Depois de estabelecida a conexo,
voc tem acesso direto aos arquivos do servidor, dentro das permisses da sua conta de
usurio. Voc pode tambm especificar diretamente uma pasta no servidor remoto que
quer acessar (por padro voc cai na pasta home), como em
"fish://gdh@gdhn.com.br/home/revista/".

Para tornar as coisas mais prticas, eu uso o recurso de dividir a janela em duas, que
voc encontra no "Janela > Separar viso em topo/base". Assim, fico com uma janela
mostrando os arquivos locais e outra mostrando os arquivos do servidor, e posso
simplesmente arrastar os arquivos que devem ser transferidos:

20
O Konqueror no muito bom em prever erros com a conexo, se limitando a exibir um
"no possvel se conectar ao servidor". Nesses casos, abra um terminal e experimente
tentar se conectar via texto para ver as mensagens de erro e poder assim diagnosticar o
problema.

No Nautilus, clique em "Arquivo > Conectar ao servidor". Na janela seguinte, escolha

"SSH" na opo "Tipo de servio" e fornea o endereo do servidor e o login que ser
usado, no campo "Nome do Usurio". O campo com a pasta permite especificar qual
pasta ser acessada por padro ao efetuar a conexo, mas ela opcional. O campo
"Porta" usado apenas caso voc tenha configurado o servidor SSH para escutar em
uma porta diferente da 22:

21
Isso cria um cone de acesso, que aparece tanto no desktop quanto na barra "Locais" do
Nautilus. Para finalmente efetuar o acesso, clique sobre o cone e fornea a senha.

A grande limitao do sftp (e das interfaces grficas para ele) que ele exige
interveno manual e, por isso, no adequado para uso em scripts para realizar
transferncias automatizadas (como no caso de um script de backup). Para isso, temos o
"scp", um cliente ainda mais primitivo, que permite especificar em uma nica linha o
login e endereo do servidor, junto com o arquivo que ser transferido.

22
A sintaxe do scp : "scp arquivo_local login@servidor:pasta_remota", como em:

$ scp /home/gdh/arquivo.tar gdh@gdhn.com.br:/var/www/download

Voc pode adicionar tambm as opes "-p" (que preserva as permisses de acesso alm
das datas de criao e modificao do arquivo original), "-r" (que permite copiar pastas,
recursivamente), "-v" (verbose, onde so mostradas todas as mensagens) e "-C" (que
ativa a compresso dos dados, ajudando muito na hora de transferir grandes arquivos via
Internet). Nesse caso, o comando ficaria:

$ scp -prvC /home/gdh/arquivo.tar gdh@gdhn.com.br:/var/www/download

Ao incluir a opo "-r", voc pode especificar diretamente uma pasta no primeiro
parmetro, o que faz com que todo o seu contedo seja transferido. Esta opo
interessante para backups.

O SSH pode ser ainda usado como "meio de transporte" por outros programas, como no
caso do rsync, um utilitrio que permite sincronizar uma pasta local com uma pasta do
servidor. Ele capaz de fazer uma cpia diferencial, transferindo apenas os trechos dos
arquivos que foram modificados o que o torna um utilitrio quase que ideal para backup
de pastas com um grande volume de arquivos. Ele capaz inclusive de consertar
arquivos danificados e dar upload de atualizaes, enviando apenas as partes dos
arquivos que forem diferentes, o que torna a transferncia muito mais rpida.

O uso bsico do rsync, para sincronizar duas pastas locais, seria "rsync -a origem/
destino/". A pasta destino poderia ser um segundo HD, um carto de memria ou um
compartilhamento de rede, por exemplo. Usado dessa forma, o rsync serve apenas para
fazer backups locais, mas, ao combin-lo com o SSH, abrimos uma nova gama de
possibilidades.

Para usar o rsync via SSH, o comando acaba sendo bem mais complexo, mas o
resultado bem interessante. Ele vai apenas atualizar as partes dos arquivos remotos
que foram modificados, sem dar upload dos arquivos inteiros novamente, como muitos
programas de backup fariam.

Para sincronizar a pasta local "/home/gdh" com a pasta remota "/backup", no servidor
"gdhn.com.br" (onde seria feito um backup dos arquivos locais), usando o login "gdh",
por exemplo, o comando seria:

$ rsync -av --rsh="ssh -l gdh" /home/gdh/ gdh@gdhn.com.br:/backup

Para recuperar posteriormente o backup no caso de um desastre, baixando os arquivos

salvos no servidor, bastaria inverter a ordem dos diretrios no comando, como em:

$ rsync -av --rsh="ssh -l gdh" gdh@gdhn.com.br:/backup /home/gdh/

23
No primeiro comando os arquivos da pasta "/home/gdh" vo para a pasta /backup do
servidor e no segundo eles so recuperados, subscrevendo os arquivos locais. A parte
mais significativa deste comando o parmetro "--rsh="ssh -l gdh", que diz para o rsync
usar um programa externo (o SSH) para fazer o trabalho.

Uma observao que usando apenas os parmetros "-av", o rsync apenas atualiza e
grava novos arquivos na pasta do servidor, sem remover arquivos que tenham sido
deletados na pasta local. Por um lado isso bom, pois permite recuperar arquivos
deletados acidentalmente, mas por outro pode causar confuso. Se voc preferir que os
arquivos que no existem mais sejam deletados ao atualizar o backup, adicione o
parmetro "--delete", como em:

$ rsync -av --delete --rsh="ssh -l gdh" /home/gdh/

gdh@gdhn.com.br:/backup

O rsync no vem instalado por padro na maioria das distribuies, mas pode ser
instalado rapidamente usando o gerenciador de pacotes, como em:

# apt-get install rsync

Criando tneis seguros

Uma forma simples de encriptar protocolos que em condies normais no suportam

encriptao usar o SSH para criar tneis seguros, ligando uma das portas da sua
mquina porta do servidor onde o servio em questo est ativo. Nesse caso, criada
uma espcie de VPN temporria, atravs da qual possvel acessar o servio de forma
segura. Todas as informaes transmitidas so encriptadas pelo SSH, tornando seguros
mesmo protocolos "escancarados", como o Telnet e o FTP. Um dos usos mais comuns
para este recurso encriptar sesses do VNC, evitando que pessoas mal intencionadas
tenham acesso ao que foi feito dentro da sesso, mesmo que ela seja interceptada.

O VNC utiliza uma chave de encriptao de mo nica durante a autenticao, de forma

que a senha no circula abertamente pela rede. Isso impede que algum sniffando a rede
consiga capturar sua senha do VNC, como acontece no caso do Telnet, por exemplo.
Apesar disso, o algoritmo de encriptao de senha usado pelo VNC no muito seguro
e, depois que a conexo iniciada, os dados so enviados de forma no-encriptada,
abrindo a possibilidade de que algum capaz de capturar os pacotes transmitidos possa
ver o que voc est fazendo e at mesmo capturar as teclas digitadas no teclado.

Se voc utiliza o VNC para tarefas sensveis, como administrar servidores, acessar
sistemas bancrios, etc., pode implantar uma camada extra de segurana, utilizando o
VNC em conjunto com o SSH. Nesse caso, a segurana quase total, pois alm de ser
necessria uma dupla autenticao (primeiro no SSH e depois no VNC), todos os dados
so transmitidos atravs da rede de forma encriptada, utilizando um algoritmo
reconhecidamente seguro.

24
Para utilizar o SSH em conjunto com o VNC, utilizamos a opo "-L", que permite
redirecionar uma determinada porta local para uma porta no servidor, criando o tnel. A
sintaxe do SSH, neste caso, seria "ssh -L porta_local:servidor:porta_do_servidor
servidor". Parece complicado, mas vai melhorar... :)

O servidor VNC escuta na porta 5900 + o nmero do display (5901, 5902, 5903, etc.).
Note que a porta diferente do servidor Java, acessvel utilizando o browser, que utiliza
as portas de 5800 em diante.

Se voc vai acessar o display 1 (porta 5901), na mquina 220.132.54.78, precisamos

orientar o SSH a redirecionar esta porta para uma porta acessvel pelo cliente VNC (a
prpria porta 5901, ou qualquer outra) no PC local. Para isso, necessrio que o
servidor SSH esteja aberto no servidor remoto e que voc tenha uma conta nele. O
comando seria:

$ ssh -f -N -L5901:220.132.54.78:5901 -l login 220.132.54.78

Substitua o "login" pela sua conta de usurio na mquina remota. O SSH pedir a senha
(ou passphrase) e, pronto, o tnel estar criado.

Tudo o que voc precisa fazer agora abrir o cliente VNC e acessar o endereo
"127.0.0.1:1". Isso far com que o cliente acesse a porta 5901 na mquina local, que por
sua vez ser redirecionada (atravs do tnel) para a porta 5901 do servidor remoto. Voc
usar o VNC da mesma forma, mas desta vez usando um tnel seguro.

Se por acaso a porta 5901 local j estiver em uso, voc pode simplesmente criar o tnel
apontando para outra porta da sua mquina. Se voc fosse acessar o display 4 (porta
5904) no servidor 192.168.0.4, redirecionando-o para a porta 5905 (display 5) da
mquina local, logando-se usando o usurio "tux", o comando seria:

$ ssh -f -N -L5905:192.168.0.4:5904 -l tux 192.168.0.4

Nesse caso, voc acessaria o endereo "127.0.0.1:5" no cliente VNC, que faz com que
ele se conecte na porta 5905.

A desvantagem de utilizar o SSH em vez de acessar o servidor VNC diretamente que a

atualizao de tela ficar um pouco mais lenta, pois o servidor ter dois trabalhos, o de
compactar os dados usando um dos algoritmos do VNC e, em seguida, encriptar os
pacotes usando a chave do SSH, uma dupla jornada. Entretanto, se pensarmos do ponto
de vista da segurana, a troca acaba sendo vantajosa.

Alm do VNC, este comando pode ser usado para criar tneis para outras portas. Para
redirecionar portas privilegiadas, da 1 a 1024, voc precisa executar o comando como
root. Para as portas altas (como as usadas pelo VNC), voc pode usar um login normal
de usurio.

25
O parmetro "-f" dentro do comando faz com que ele seja executado em background,
liberando o terminal depois que a conexo estabelecida. O "-N" faz com que o SSH
apenas crie o redirecionamento da porta, sem abrir um terminal do servidor remoto,
enquanto o "-L" a opo principal, que especifica que queremos fazer um
redirecionamento de portas. Ele seguido (sem espaos) pela porta local que receber a
porta remota, o endereo do servidor e a porta do servidor que ser redirecionada ("-
L2525:192.168.0.4:25" redireciona a porta 25 do servidor remoto para a porta 2525 da
mquina local). Concluindo, o "-l" em seguida especifica o login que ser usado para
estabelecer a conexo, seguido pelo endereo IP do servidor.

Em resumo, a sintaxe deste longo comando "ssh -f -N -Lporta-local:servidor:porta-

do-servidor -l login servidor" (veja que necessrio especificar o endereo do servidor
remoto duas vezes).

Seja qual for a porta destino, todo o trfego transportado atravs da porta do SSH e
encaminhada localmente para a porta final. Graas a essa peculiaridade, os tneis so
uma forma muito usada para acessar ferramentas como o Webmin, phpMyAdmin ou
Swat em servidores remotos, sem precisar manter as respectivas portas abertas para toda
a Internet. Basta que a porta 22 (ou outra em que o servidor SSH esteja escutando)
esteja aberta para que voc consiga acessar qualquer outra usando tneis. Em casos em
que o servidor remoto esteja configurado para usar uma porta diferente da padro para o
SSH, adicione a opo "-p porta" no incio do comando, como em:

# ssh -p 2222 -f -N -L901:gdhn.com.br:901 -l login gdhn.com.br

Continuando, um segundo exemplo interessante de uso seria usar um tnel para

encriptar todo o trfego web, de forma que voc possa navegar de forma segura, ler seus
e-mails, etc. mesmo ao acessar atravs de uma conexo wireless sem qualquer tipo de
encriptao.

Para isso, preciso que o gateway da rede (ou alguma mquina na Internet, que seja
acessvel por voc) esteja com um servidor proxy aberto (se voc estiver usando o
Squid, por exemplo, o proxy ficar aberto na porta 3128 do servidor). Podemos usar
ento o SSH para criar um tnel, ligando a porta 3128 do servidor porta 3128 (ou
qualquer outra) do seu micro, como em:

$ ssh -f -N -L3128:gdhn.com.br:3128 -l tux gdhn.com.br

O prximo passo configurar o navegador na sua mquina para acessar usando o proxy.
Entretanto, em vez de configurar o navegador para acessar o proxy diretamente, vamos
configur-lo para procurar o proxy na porta 3128 do localhost. Isso faz com que todos
os acessos sejam direcionados ao tnel criado atravs do SSH e cheguem at o proxy de
forma encriptada:

26
Para ser usado dessa forma, o proxy rodando no servidor remoto deve ser configurado
para aceitar conexes de qualquer cliente, j que mesmo passando pelo tnel, o acesso
ser computado pelo Squid como partindo do seu IP de Internet atual. Um exemplo de
configurao do Squid para que o servidor permitisse a conexo de qualquer cliente
remoto seria:

http_port 3128
visible_hostname gdh
acl all src 0.0.0.0/0.0.0.0
acl manager proto cache_object
acl localhost src 127.0.0.1
acl SSL_ports port 443 563
acl Safe_ports port 21 80 443 563 70 210 280 488 59 777 901 1025-65535
acl purge method PURGE
acl CONNECT method CONNECT
http_access allow manager localhost
http_access deny manager
http_access allow purge localhost
http_access deny purge
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow all

27
Como voc pode ver, essa configurao simplesmente permite acessos provenientes de
qualquer endereo. O truque que como o servidor ser acessado atravs dos tneis
criados usando o SSH, voc pode manter a porta 3128 fechada no firewall do servidor,
permitindo apenas conexes atravs da porta 22. Com isso, o servidor no ficar
vulnervel, j que a nica forma de chegar at o proxy criando um tnel at ele atravs
do SSH.

SSH no Windows

Existem diversas verses do SSH. A maioria das distribuies Linux inclui o OpenSSH,
que no possui um cliente para Windows. No entanto, isso no chega a ser um
problema, pois o SSH um protocolo aberto, o que permite o desenvolvimento de
clientes para vrias plataformas, inclusive Windows. Eles so usados por muita gente
para administrar servidores Linux remotamente.

Um exemplo de cliente simples e gratuito o PuTTY, que inclui tambm o PSFTP, um

cliente de SFTP, que permite tambm transferir arquivos usando os comandos de
transferncia que j vimos (put, get, cd, lcd, pwd, lpwd, etc.). Ambos podem ser
baixados no: http://www.putty.nl/

Usar o PuTTY para se conectar a servidores Linux bem simples, pois ele no precisa
sequer ser instalado. Basta baixar o arquivo e execut-lo:

28
O PuTTY tambm permite criar tneis encriptados. Para isso, comece colocando o IP ou
o domnio do servidor a que vai se conectar no campo "Host Name (or IP address)" na
tela principal, como se estivesse abrindo uma conexo normal, mas, ao invs de clicar
no "open", acesse a opo "Connection > SSH > Tunels".

Na opo "source port" vai a porta do seu micro que receber o tnel (3128, por
exemplo) e no "Destination" vai o endereo IP ou domnio do servidor remoto a que
voc est se conectando, seguido da porta, como em "meuservidor.com.br:3128". Clique
no "Add" (voc pode adicionar vrias portas) e em seguida no "Open", para abrir a
conexo.

Outro exemplo de cliente SSH para Windows a verso da SSH Security, que possui
vrios recursos mas gratuita apenas para universidades e usurios domsticos e por
isso bem menos usada. O link : http://www.ssh.com

O PuTTY e o SSH da SSH Security so inteiramente compatveis com o OpenSSH. A

grande limitao que esses dois clientes so limitados ao modo texto, pois para exibir
aplicativos grficos via SSH, necessrio que o sistema cliente possua um servidor X,
coisa que o Windows no possui nativamente. Ao tentar abrir qualquer aplicativo
grfico, voc recebe a fatdica mensagem "cannot connect to X server". Tambm no
existem servidores SSH "de verdade" para Windows, que permitam administrar um
servidor Windows remotamente. As solues de servidores SSH para Windows se

29
concentram nos recursos de encriptao para transferncias de arquivos e criao de
tneis.

Voltando ao tema principal, existem alguns servidores X para Windows, que abrem uma
sesso do X dentro de uma janela, como o X-Win32 (http://xwin32.dk) e o WinaXe
(http://labf.com), mas uma opo muito melhor o Xming, um software gratuito e de
cdigo aberto, disponvel no:
http://www.straightrunning.com/XmingNotes/.

Quando aberto, o Xming fica residente ao lado do relgio, esperando que algum
aplicativo precise dele. Para us-lo em conjunto com o PuTTY, marque (no PuTTY) a
opo "Connection > SSH > X11 > Enable X11 forwarding" (sem colocar nada no
campo "X display location"). Isso faz com que o PuTTY encaminhe todas as requisies
grficas para o Xming, permitindo que os aplicativos grficos rodem normalmente,
mesmo no Windows. Embora no seja uma soluo muito elegante, realmente funciona:

30
O Xming resolve o problema do uso de aplicativos grficos via SSH no Windows, mas
ele ainda no a soluo ideal para muitas situaes, j que exige uma certa dose de
configurao e o uso centralizado em torno do terminal. Se voc est procurando uma
soluo mais prtica e simples, a melhor opo o Cliente NX, que (uma vez
configurado o servidor) muito mais simples de usar e oferece uma performance muito
melhor que a obtida ao rodar aplicativos grficos atravs do SSH "puro", graas s
vrias otimizaes utilizadas. Veremos mais detalhes sobre ele logo a seguir.

Voc pode baixar o cliente NX for Windows no http://nomachine.com. No site, voc

pode fazer um "testdrive", acessando um dos servidores da empresa. O NX trabalha
sobre o SSH, implementando um conjunto de otimizaes para reduzir o trfego e a
latncia das conexes. O resultado algo similar ao VNC, mas com um desempenho
bem melhor. Ao contrrio do PuTTY, no NX tudo feito atravs de um cliente grfico:

31
Na hora de transferir arquivos via SFTP, uma boa opo o FileZilla, um cliente de FTP
grfico e bastante amigvel, que inclui suporte ao SFTP. Voc pode baix-lo no:
http://filezilla.sourceforge.net/

Para conectar via SFTP, use a opo "File > Site Manager > New Site" para criar a
conexo. S assim voc tem acesso opo de usar o SFTP, j que os campos na tela
principal servem apenas para servidores FTP:

32
Na tela seguinte, informe o IP do servidor, a porta (22) e a conta de acesso. Uma vez
conectado, voc acessa os arquivos usando a interface tradicional dos clientes de FTP,
com as duas janelas, uma mostrando os arquivos locais e outra mostrando os do
servidor. Para transferir arquivos, basta arrast-los entre as duas.

33