Baixe Dominando o SSH e outras Notas de estudo em PDF para Engenharia Informática, somente na Docsity!
Dominando o SSH
O SSH é a minha ferramenta preferida. Ele permite administrar máquinas remotamente, executando inclusive aplicativos gráficos, permite transferir arquivos de várias formas diferentes e, como se não bastasse, permite também encapsular outros protocolos, permitindo, por exemplo, acessar uma sessão do VNC através de um túnel seguro.
A grande vantagem do SSH sobre outras ferramentas de acesso remoto é a grande ênfase na segurança. Um servidor SSH bem configurado é virtualmente impenetrável e você pode acessá-lo de forma segura, mesmo que a sua rede local esteja comprometida. Ele utiliza um conjunto de técnicas de criptografia para assegurar que apenas as pessoas autorizadas terão acesso ao servidor, que todos os dados transmitidos sejam impossíveis de decifrar e que a integridade da conexão seja mantida.
São previstas respostas para diversos tipos de ataques conhecidos. O SSH detecta casos em que o servidor tenha sido substituído por outra máquina, situações nas quais se tenta injetar dados na conexão, ou seja, tirar proveito de uma conexão aberta para incluir pacotes com comandos adicionais e inclui até mesmo técnicas 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 força-bruta.
A idéia central é que, mesmo em situações onde seja fácil interceptar a transmissão (como no caso de uma rede wireless pública), seja impossível descobrir o conteúdo dos pacotes, devido à encriptação. É possível, ainda, utilizar um par de chaves ao invés de uma simples senha como forma de autenticação. Nesse caso, além da chave (um arquivo salvo no HD, pendrive ou smartcard), é preciso saber a passphrase, que pode ser uma senha especialmente longa e difícil de adivinhar.
Qualquer algoritmo de encriptação pode ser quebrado via força bruta, onde simplesmente são testadas todas as possibilidades possíveis, até encontrar a combinação correta. Porém, isso só é realmente possível para chaves de 40 ou no máximo 64 bits; acima disso é inviável, pois a cada bit adicionado, o processo torna-se exponencialmente mais demorado.
O WEP de 64 bits (que na verdade utiliza uma chave de 40 bits), usado em redes wireless pouco protegidas, pode ser quebrado em pouco tempo, caso você consiga capturar um volume considerável de transmissões usando um sniffer. O DES, um dos algoritmos mais tradicionais, que usa chaves de 64 bits (reais), pode ser quebrado em alguns dias, caso você tenha acesso a um cluster de 100 máquinas Athlon 64.
Uma chave de 64 bits é cerca de 16 milhões de vezes mais difícil de quebrar via força bruta do que uma de 40 bits, como as que eram utilizadas no SSL dos navegadores a até poucos anos atrás. 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 necessários à disposição, mas uma de 128 (sem brechas conhecidas) é impossível de quebrar com tecnologia atual.
O perigo no caso dos algoritmos de encriptação é quando são descobertas falhas que permitam descobrir a chave usada em menos tempo. As versões originais do WEP, 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 encriptação dos DVDs, que é quebrado em poucos segundos por uma máquina atual, utilizando um algoritmo de poucas linhas.
Felizmente, este não é 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 código é exaustivamente auditado por uma variedade de empresas e órgãos governamentais.
O SSH utiliza chaves assimétricas para fazer a autenticação. As chaves assimétricas são um sistema muito interessante, onde temos um par de chaves. Uma (a chave pública), permite apenas encriptar dados, enquanto a segunda (a chave privada) permite desencriptar as informações embaralhadas pela primeira.
Quando você se conecta a um servidor SSH, seu micro e o servidor trocam suas chaves públicas, permitindo que um envie informações para o outro de forma segura. Através deste canal inicial é feita a autenticação, 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 configuração). O problema é que, embora impossível de quebrar, este nível de encriptação demanda uma quantidade muito grande de processamento. Se todas as informações fossem transmitidas desta forma, o SSH seria muito lento.
Para solucionar este problema, depois de fazer a autenticação, o SSH passa a utilizar um algoritmo mais simples, que demanda muito menos processamento, para transmitir os dados. Por padrão é utilizado o 3DES (triple-DES), que utiliza uma combinação de três chaves DES, de 64 bits cada. As chaves são trocadas periodicamente durante a conexão, o que torna o sistema quase impossível de quebrar. Na configuração do servidor e/ou cliente, é possível especificar outro algoritmo, como o Blowfish. Isso garante uma boa relação entre segurança e desempenho.
O SSH é dividido em dois módulos. O sshd é o módulo servidor, um serviço que fica residente na máquina que será acessada, enquanto o ssh é o módulo cliente, um utilitário que você utiliza para acessá-lo.
Nas distribuições derivadas do Red Hat, o servidor SSH é instalado através do pacote " openssh-server " e o cliente, através do " openssh-clients ". No Debian, ambos são instalados através do pacote " ssh ". Com o pacote instalado, você inicia o servidor usando o comando " service sshd start " (nos derivados do Red Hat), ou " /etc/init.d/ssh start ", no caso do Debian. Para que ele seja inicializado durante o boot, use respectivamente o " chkconfig sshd on " ou " update-rc.d -f ssh defaults ".
A partir daí as coisas se unificam. A configuração do servidor, independentemente da distribuição usada, vai no arquivo " /etc/ssh/sshd_config ", enquanto a configuração do
".ssh/known_hosts" dentro do seu diretório home. Sempre que você se conecta daí em diante, o cliente SSH envia um "desafio" ao servidor, uma frase encriptada usando a chave pública, que só pode ser descoberta usando a chave privada.
Isso previne um tipo de ataque muito comum chamado "man in the middle" (que poderia ser traduzido para "intermediário", ou "impostor"), em que alguém simplesmente substitui o servidor por outra máquina, usando o mesmo IP, ou sabota o servidor DNS da rede (ou do provedor) de forma que ele entregue um IP forjado quando você tenta acessar seu servidor baseado no domínio.
O servidor falso pode ser configurado para gravar sua senha e responder com uma mensagem do tipo "O servidor está em manutenção, tente novamente daqui a algumas horas". Dessa forma, ele vai ter não apenas acesso à sua senha, mas tempo para usá-la para acessar o servidor verdadeiro sem que você desconfie. Por sorte, o SSH percebe que a identificação do servidor mudou e lhe avisa do problema:
Para continuar é preciso que você edite manualmente o arquivo " .ssh/known_hosts ", dentro do home e remova a linha com a antiga identificação do servidor, deixando as demais. Da próxima vez que tentar se conectar, o SSH exibe uma mensagem mais simpática, 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)?
Não existe forma de fazer com que o cliente SSH adicione as novas chaves automaticamente, isso seria uma brecha de segurança. É sempre preciso primeiro remover a chave antiga no arquivo "~/known_hosts" manualmente.
As chaves são geradas durante a instalação do SSH e salvas nos arquivos "/etc/ssh/ssh_host_rsa_key" e "/etc/ssh/ssh_host_dsa_key" (no servidor). Para não disparar o alarme nos clientes quando precisar reinstalar o servidor, salve os dois arquivos em um pendrive e restaure-os depois da instalação. Você pode fazer isso mesmo ao migrar para outra distribuição, pois as localizações dos dois arquivos não mudam.
Uma opção, seria desabilitar a checagem das chaves, adicionando a linha "StrictHostKeyChecking no" na configuração dos clientes. Contudo, isso não é recomendável, pois desabilita completamente a checagem, abrindo brechas para ataques.
- Compressão : No caso de servidores acessíveis via internet, você pode reduzir um pouco o consumo de banda ativando a compressão de dados via gzip, o que é feito adicionado a linha:
Compression = yes
Você pode também ativar a compressão adicionando a opção "-p" na hora de se conectar. Quase todas as opções do cliente SSH podem ser especificadas tanto no arquivo, quanto via linha de comando.
- Aplicativos gráficos : Além de oferecer acesso via linha de comando, o SSH permite rodar aplicativos gráficos remotamente (X11 forwarding). Algumas distribuições, como o Slackware, trazem o recurso desabilitado por padrão. Nestes casos, edite o arquivo " /etc/ssh/ssh_config " (a configuração do cliente) e substitua a linha "ForwardX11 no" por:
ForwardX11 yes
Outra opção é adicionar o parâmetro "-X" ao se conectar, como em "ssh -X [email protected]". A partir daí, você pode chamar os aplicativos gráficos normalmente, como se estivesse num terminal local.
O maior problema com o uso de aplicativos remotos via SSH é que ele só funciona satisfatoriamente via rede local. Via internet os aplicativos gráficos ficam realmente muito lentos (mesmo em uma conexão de 1 ou 2 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 próprio servidor.
Para rodar aplicativos gráficos de forma segura via internet, a melhor solução é usar o NX Server. 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 conexões via modem.
- Keep Alive : Concluindo a configuração do cliente, outro problema comum é a conexão ser fechada pelo servidor depois de alguns minutos de inatividade. Em muitas situações você quer manter a conexão aberta por longos períodos, sem precisar ficar dando um "ls" a cada dois minutos para manter a conexão aberta. Você pode evitar o problema fazendo com que o próprio cliente mande pacotes periodicamente a fim de manter a conexão aberta. Para ativar isso, adicione a linha abaixo no "/etc/ssh/ssh_config":
ServerAliveInterval 120
Note que especificamos nesta opção o próprio IP do servidor na interface escolhida, não a faixa de IP's da rede local ou os endereços que terão acesso a ele.
- Protocolo : Atualmente utilizamos o SSH 2, mas ainda existem alguns poucos clientes que utilizam a primeira versão do protocolo. Por padrão, o servidor SSH aceita conexões de clientes que utilizam qualquer um dos dois protocolos, o que é indicado na linha:
Protocol 2,
O protocolo SSH 1 tem alguns problemas fundamentais de segurança, por isso alguns administradores preferem desabilitar a compatibilidade com ele, aceitando apenas clientes que usam o SSH 2. Neste caso, a linha fica apenas "Protocol 2"
- Usuários e senhas : Outra opção interessante, logo abaixo é a:
PermitRootLogin yes
Esta opção determina se o servidor aceitará que usuários se loguem como root. Do ponto de vista da segurança, é melhor deixar esta opção como "no", pois assim o usuário precisará primeiro se logar usando um login normal e depois virar root usando o "su" ou "su -". Desta forma, será preciso saber duas senhas, ao invés de saber apenas a senha do root.
Por padrão, o SSH permite que qualquer usuário cadastrado no sistema se logue remotamente, mas você pode refinar isso através da opção "AllowUsers", que especifica uma lista de usuários que podem usar o SSH. Quem não estiver na lista, continua usando o sistema localmente, mas não consegue se logar via SSH. Isso evita que contas com senhas fracas, usadas por usuários que não têm necessidade de acessar o servidor remotamente coloquem a segurança do sistema em risco. Para permitir que apenas os usuários joao e maria possam usar o SSH, adicione a linha:
AllowUsers joao maria
Você pode ainda inverter a lógica, usando a opção "DenyUsers". Nesse caso, todos os usuários cadastrados no sistema podem fazer login, com exceção dos especificados na linha, como em:
DenyUsers ricardo manoel
Outra opção relacionada à segurança é a:
PermitEmptyPasswords no
Esta opção faz com que qualquer conta sem senha fique automaticamente desativada no SSH, evitando que alguém consiga se conectar ao servidor "por acaso" ao descobrir a conta desprotegida. Lembre-se que a senha é justamente o ponto fraco do SSH. De nada adianta usar 2048 bits de encriptação se o usuário escreve a senha num post-it colado no monitor, ou deixa a senha em branco.
- Banner : Alguns servidores exibem mensagens de advertência antes do prompt de login, avisando que todas as tentativas de acesso estão sendo monitoradas ou coisas do gênero. A mensagem é especificada através da opção "Banner", onde você indica um arquivo de texto com o conteúdo a ser mostrado, como em:
Banner = /etc/ssh/banner.txt
- X11 Forwarding : Um pouco depois temos a opção:
X11Forwarding yes
Esta opção determina se o servidor permitirá que os clientes executem aplicativos gráficos remotamente. Se o servidor será acessado via internet ou se possui um link lento, você pode deixar esta opção como "no" para economizar banda. Desta forma, os clientes poderão executar apenas comandos e aplicativos de modo texto.
- Módulos : O SSH inclui um módulo de transferência de arquivos (o SFTP), que veremos em detalhes a seguir. Ele é ativado através da linha:
Subsystem sftp /usr/lib/sftp-server
É realmente necessário que esta linha esteja presente para que o SFTP funcione. Comente esta linha apenas se você realmente deseja desativá-lo.
Usando chaves de autenticação
Ao invés de depender unicamente da senha como forma de autenticação, o SSH permite o uso de um par de chaves, onde a chave pública é instalada nos servidores que serão acessados e a chave privada (que nunca sai da sua máquina) é protegida por uma passphrase.
Nesse caso, temos uma segurança de dois níveis, em que é preciso saber a passphrase e, além dela, ter a chave privada, um arquivo salvo no HD ou em um pendrive, algo similar ao sistema bancário, onde você precisa ter o cartão e saber a senha. Para gerar o par de chaves, use o comando:
$ ssh-keygen -t rsa
Ele é sempre executado usando seu login de usuário, não 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.
Você pode instalar a chave manualmente simplesmente logando-se na máquina remota, via SSH e copiando a linha para dentro do arquivo ".ssh/authorized_keys", o que pode ser feito copiando o texto e colando através de qualquer editor de textos que suporte esta função, como o joe ou o vi.
No final, o arquivo ".ssh/authorized_keys" da máquina remota (dentro do home) terá o mesmo conteúdo do arquivo ".ssh/id_rsa.pub" da sua máquina, o que orienta o servidor remoto a passar a checar sua chave privada e passphrase, ao invés de pedir senha.
Continuando, é possível ainda deixar a passphrase em branco na hora de gerar as chaves, o que faz com que o login passe a ser automático. Isso torna as coisas muito práticas, pois você pode escrever até mesmo scripts para copiar arquivos via SFTP, sem precisar se preocupar com senhas, mas não é necessariamente uma boa idéia, pois alguém que consiga copiar sua chave privada poderia ganhar acesso irrestrito a seu servidor.
Não é algo tão corriqueiro quanto pode parecer, pois a chave privada nunca sai do seu micro. O servidor remoto envia um "desafio" para o cliente na sua máquina e a chave é apenas usada para processar a resposta. Para roubar sua chave privada, seria necessário que alguém efetivamente invadisse o sistema, ou tivesse acesso físico ao seu micro, para dar boot com o live-CD e copiar o arquivo para um pendrive. De qualquer forma, não é bom dar sopa para o azar.
A melhor forma de usar chaves sem precisar ficar digitando a passphrase toda hora é usar o " ssh-agent ". Ele funciona como uma espécie de "cache", onde você digita a passphrase apenas uma vez, depois de inicializar o sistema, e ela fica gravada na memória até que a sessão seja encerrada.
A segurança não é prejudicada, pois a passphrase não é salva em lugar algum, fica apenas armazenada (de forma encriptada) em uma área protegida de memória, acessível apenas ao ssh-agent. Ao desligar o micro, tudo é perdido.
Para usar o ssh-agent, abra um terminal e use os comandos:
$ 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 memória e você não precisa mais se preocupar até o próximo reboot. Uma forma prática de fazer com que os dois comandos sejam executados automaticamente durante a abertura do sistema, é adicioná-los em um ícone dentro da pasta ".kde/Autostart", dentro do seu diretório home. Note que eles não devem ser adicionados no bootmisc.sh, rc.local ou outro arquivo de inicialização, pois precisamos que os comandos sejam executados dentro do seu login de usuário e não pelo root.
Até aqui, aprendemos como utilizar uma única chave. É comum que seja usada uma única chave para acessar vários micros. Isso não representa um risco de segurança, desde que você escolha uma boa passphrase.
Porém, muitos administradores preferem trabalhar com várias chaves distintas, uma para cada servidor que será acessado, por exemplo. Isso é perfeitamente possível, embora bem mais trabalhoso. Para gerar novas chaves, rode o comando " ssh-keygen -t rsa ", prestando atenção 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):
Se você salvou a segunda chave como "id_rsa2", por exemplo, o comando para instalá- la no servidor seria "ssh-copy-id -i ~/.ssh/id_rsa2.pub seu_login@servidor". Na hora de adicionar a segunda chave no ssh-agent, você deve também especificar o nome do arquivo, como em: "ssh-add /root/.ssh/id_rsa2".
Este procedimento pode ser repetido para adicionar quantas chaves diferentes quiser, mas as coisas ficam mais trabalhosas a cada nova chave adicionada :).
Ao usar o ssh-agent para guardar suas passphrases, você pode ativar a opção ForwardAgent (no cliente) para permitir que o agente disponível na sua máquina possa ser usado para abrir novas sessões SSH quando estiver logado em outras máquinas.
Imagine que você administra dois servidores remotos: servidor A e servidor B. Você instalou a sua chave pública em ambos e armazenou sua passphrase no ssh-agent, de forma que você pode logar em ambos, a partir da sua máquina sem digitar senha. Porém, 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, pois o servidor A não tem acesso à sua chave privada, que está no seu micro.
O ForwardAgent resolve isso, permitindo que a partir da sessão aberta no servidor A, você possa se conectar no servidor B. Isso é feito de forma segura, criando um túnel temporário, diretamente entre a sua máquina e o servidor B e fazendo a verificação da chave através dele, sem passar pelo servidor A. Desta forma, não existe a possibilidade de um keytrap, ou qualquer armadilha instalada no servidor A, ser usado para capturar sua chave ou passphrase.
Para ativar este recuso, abra o arquivo " /etc/ssh/ssh_config " (na sua máquina) e adicione a opção:
ForwardAgent yes
Depois de gerar a chave e conseguir se conectar através 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.
Você pode instalá-lo rapidamente no Debian, Ubuntu ou derivados usando o apt-get:
apt-get install fail2ban
Para distribuições que não incluam o pacote, você pode baixar o código fonte no: http://sourceforge.net/projects/fail2ban
A configuração é feita através do arquivo " /etc/fail2ban/jail.conf ", onde são listados os arquivos de log que serão monitorados, o número máximo de tentativas antes de aplicar o bloqueio e o tempo que ele vigorará.
Por padrão, ele é configurado para banir por 10 minutos endereços a partir dos quais sejam feitas mais do que 5 tentativas mal-sucedidas. Além do SSH, ele monitora também os arquivos de log do apache (monitorando tentativas de acesso a pastas protegidas por senha através de arquivos .htaccess) e até mesmo tentativas de acesso ao servidor de e-mails (caso seja utilizado o postfix) ou ao servidor FTP.
O tempo de banimento é especificado (em segundos) através da opção "bantime" dentro do arquivo, como em:
bantime = 600
O número de tentativas toleradas para cada serviço, assim como seu respectivo arquivo de log (que o fail2ban monitora, identificando as tentativas de login que não foram bem sucedidas) são especificados em uma seção separada, como em:
[ssh] enabled = true port = ssh filter = sshd logpath = /var/log/auth.log maxretry = 6
É possível também criar uma lista branca de endereços que nunca serão bloqueados, independentemente do número de tentativas, através da opção "ignoreip". Se você administra seus servidores a partir de um link com IP fixo, é interessante colocar seu endereço na lista, para evitar acidentes. Você pode especificar vários endereços, separando-os com espaços, como em:
ignoreip = 127.0.0.1 200.23.43.65 201.34.21.
Depois de fazer modificações no arquivo, reinicie o serviço com o comando:
/etc/init.d/fail2ban restart
Transferindo arquivos
O SSH é um verdadeiro canivete suíço. Além de permitir rodar aplicativos e fazer toda a administração de um servidor remotamente, ele também pode ser usado para transferir arquivos. A forma mais básica de fazer isso é usar o sftp , um comando que faz parte do pacote padrão.
Ele oferece uma interface similar à dos antigos programas de FTP de modo texto, mas todos os arquivos transferidos através dele trafegam através de um túnel encriptado, criado através do SSH. Na prática, temos uma espécie de VPN temporária, criada no momento em que é efetuada a conexão. A melhor parte é que o próprio SSH cuida de tudo, não é necessário instalar nenhum programa adicional.
Para se conectar a um servidor usando o sftp, o comando é:
$ sftp [email protected].
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 parâmetro -o port=, como em:
$ sftp -o port=22 [email protected].
A partir daí você tem um 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 diretório), " ls " (para listar os arquivos) e " pwd " (para ver em qual diretório está). Veja um exemplo:
morimoto@athenas:~$ sftp -o port=2222 [email protected]. Connecting to 10.0.0.1... Password:
sftp> ls Desktop Meu Computador OpenOffice.org1.1.1a icones-magicos.deb
sftp> get icones-magicos.deb Fetching /home/kurumin/icones-magicos.deb to icones-magicos.deb /home/kurumin/icones-magicos.deb 100% 825KB 825.1KB/s 00:
sftp> put RealPlayer10GOLD.bin Uploading RealPlayer10GOLD.bin to /home/kurumin/RealPlayer10GOLD.bin RealPlayer10GOLD.bin 100% 6726KB 3.3MB/s 00:
sftp> pwd Remote working directory: /home/morimoto
Uma forma mais primitiva de transferir arquivos via SSH é usar o " scp ", que permite especificar em uma única linha o login e endereço do servidor, junto com o arquivo que será transferido. Graças a isso, ele é muito usado em scripts. A sintaxe do scp é: "scp arquivo_local login@servidor:pasta_remota", como em:
$ scp /home/arquivo.tar [email protected]:/var/www/download
Você pode adicionar também as opções " -p " (que preserva as permissões de acesso além das datas de criação e modificação do arquivo original), " -r " (que permite copiar pastas, recursivamente), " -v " (verbose, onde são mostradas todas as mensagens) e " -C " (que ativa a compressão dos dados, ajuda muito na hora de transferir grandes arquivos via internet). Nesse caso, o comando ficaria:
$ scp -prvC /home/arquivo.tar [email protected]:/var/www/download
Ao incluir a opção " -r ", você pode especificar diretamente uma pasta no primeiro parâmetro. Esta opção é interessante para backups.
O SSH pode ser ainda usado como "meio de transporte" por outros programas. Por exemplo, o rsync é um comando que permite sincronizar uma pasta local com uma pasta do servidor (para fazer backup, por exemplo). Ele é capaz inclusive de consertar arquivos danificados e dar upload de atualizações, enviando apenas as partes dos arquivos que forem diferentes, o que torna a transferência muito mais rápida.
Para instalar o rsync no Debian, use o comando "apt-get install rsync". Não vou falar muito sobre o rsync em si, pois a idéia é só dar mais um exemplo de como ele poderia ser usado em conjunto com o SSH.
O uso básico do rsync, para sincronizar duas pastas locais seria "rsync -a origem/ destino/". A pasta destino poderia ser um segundo HD, um cartão de memória ou um compartilhamento de rede, por exemplo.
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 que forem modificadas, sem dar upload dos arquivos inteiros novamente, como muitos programas de backup fariam.
Para sincronizar a pasta local " /home/joao " com a pasta remota " /backup ", no servidor 64.246.47.76 (onde seria feito um backup dos arquivos locais), usando o login "joao", por exemplo, tudo via SSH, o comando seria:
$ rsync -av --rsh="ssh -l joao" / home/joao/[email protected] : /backup
Para recuperar posteriormente o backup no caso de um desastre, baixando os arquivos salvos no servidor bastaria inverter a ordem dos diretórios no comando:
$ rsync -av --rsh="ssh -l joao " [email protected] : /backup / home/joao/
No primeiro comando os arquivos da pasta "/home/joao" vão para a pasta /backup do servidor e no segundo eles são recuperados, subscrevendo os arquivos locais. A parte
mais significativa deste comando é o parâmetro "--rsh="ssh -l joao", que diz para o rsync usar um programa externo (o SSH) para fazer o trabalho.
Uma observação é que usando apenas os parâmetros "-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 isto é bom, pois permite recuperar arquivos deletados acidentalmente, mas por outro pode causar confusão. Se você preferir que os arquivos que não existem mais sejam deletados ao atualizar o backup, adicione o parâmetro "--delete", como em:
$ rsync -av --delete --rsh="ssh -l joao" /home/joao/ [email protected]:/backup
Usando o shfs
Mesmo usando o "fish://" do Konqueror, o acesso aos arquivos do servidor remoto não é tão transparente quanto ao montar um compartilhamento NFS ou Samba, pois, por baixo dos panos, ele ainda precisa transferir o arquivo inteiro antes de abri-los ou salvar. Se você tentar abrir um vídeo, por exemplo, ele vai primeiro transferir todo o arquivo para um diretório temporário e só então abri-lo.
O shfs derruba esta limitação, permitindo montar diretórios do servidor remoto, como se fossem compartilhamentos de rede, permitindo que você acesse os arquivos de forma transparente, como se fossem arquivos locais. Tudo é feito via ssh, de forma que você não precisa manter nenhum serviço adicional ativado no servidor. Toda a configuração abaixo é feita no cliente.
Para usar o shfs, é necessário ter instalado o pacote " shfs-utils ", junto com o módulo de Kernel " shfs ". Para usar algumas das opções que veremos a seguir, você vai precisar também do pacote " ssh-askpass ", por isso é importante instalá-lo também.
Vamos por partes. A página do projeto é a http://shfs.sourceforge.net/, onde você pode baixar um pacote contendo o código fonte tanto do módulo, quanto dos executáveis shfsmount e shfsumount. Comece descompactando o arquivo baixado, como em:
$ tar -zxvf shfs-0.35.tar.gz
Acesse a pasta que será criada. Para compilar o módulo "shfs", acesse a pasta " shfs/Linux-2.6/ " e rode o comando " make ". Note que para compilar o módulo, você deve ter instalados os pacotes kernel-headers e (em algumas distribuições) também o pacote "kernel-source", além dos compiladores básicos. Carregue o módulo gerado usando o comando " insmod shfs.ko ".
Para compilar e instalar os dois executáveis, concluindo a instalação, acesse a pasta " shfsmount /" e rode os comandos " make " e " make install ".
Nas distribuições derivadas do Debian, a instalação é mais simples, pois você pode instalar tudo via apt-get. Comece instalando os pacotes "shfs-utils" e "ssh-askpass":
No caso de conexões instáveis ou ao acessar servidores remotos via internet, você pode adicionar a opção " -p " (minúsculo), que torna a conexão persistente, restabelecendo o acesso caso o servidor fique temporariamente indisponível. O "-p" torna o comportamento do shfsmount bastante interessante. Mesmo que o servidor remoto seja desligado, ele continua periodicamente tentando reabrir a conexão, durante dias, caso necessário. Quando o servidor fica novamente disponível ele abre um prompt gráfico pedindo a senha novamente e remonta a pasta.
Outra vantagem do shfs é o desempenho. Por implementar um sistema de cache, que reduz o número de requisições enviadas ao servidor e maximiza o throughput, ele acaba obtendo taxas de transferência muito mais altas, sobretudo via rede local. Apenas para efeito de comparação, tendo um Sempron 2800+ como cliente, um Pentium 4 3. como servidor e uma rede de 100 megabits, obtenho, em média, 4.8 MB/s em transferências de arquivos grandes usando o "fish://" do Konqueror e pouco mais de 7. MB/s usando o shfs. Apesar do algoritmo de encriptação continuar o mesmo, o shfs consegue ser quase 50% mais rápido.
É possível fazer com que determinados diretórios sejam montados automaticamente durante o boot, via shfs. Basta colocar o comando de montagem em algum arquivo de inicialização. O problema neste caso é que ele vai abrir a tela de autenticação, pedindo a senha a cada boot, o que pode ser irritante, sobretudo se você precisar montar diretórios de vários servidores diferentes.
Uma solução é usar a dica do SSH com login automático, usando um par de chaves sem passphrase. Neste caso, gere o par de chaves como root e adicione os comandos para montar os diretórios via shfs no arquivo "/etc/init.d/bootmisc.sh" ou "/etc/init.d/rc.local". Mesmo usando uma chave sem passphrase, a segurança ainda é bem melhor do que ao usar um protocolo sem encriptação, como o NFS ou SMB.
Se preferir fazer tudo usando seu login de usuário (o que é melhor do ponto de vista da segurança), coloque os comandos em um script dentro da pasta ".kde/Autostart".
Usando o rssh
Uma das limitações do ssh, shfs e do sftp é que, ao criar uma conta de usuário, ele tem acesso não apenas aos arquivos que deve modificar, mas acesso via shell ao servidor, que pode ser usado para rodar comandos diversos e até mesmo explorar brechas de segurança locais (onde um usuário restrito do sistema pode obter privilégios adicionais).
Você pode dar um espaço de armazenamento para um amigo, onde espera que ele guarde apenas alguns backups e descobrir mais tarde que ele andou saturando a banda do servidor baixando filmes e músicas via bittorrent.
O rssh é uma resposta para esses casos. Ele permite que o usuário tenha acesso ao servidor apenas via sftp ou scp, sem ter como executar comandos adicionais. A página do projeto é http://www.pizzashack.org/rssh/.
Comece instalando o pacote "rssh", que é encontrado na maioria das distribuições. Você pode também instalar baixando o pacote .tar.gz com os fontes, disponível na página. No Debian ele está disponível via apt-get:
apt-get install rssh
Abra agora o arquivo "/etc/rssh.conf" (ou "/usr/local/etc/rssh.conf", ao instalar a partir dos fontes) e descomente as linhas:
allowscp allowsftp
Elas especificam que os usuários remotos poderão usar o scp e sftp para transferir arquivos, mas nenhum outro comando. Verifique também se o arquivo " /etc/shells " contém a linha " /usr/bin/rssh " e, caso necessário, adicione-a manualmente. Crie agora o usuário que terá acesso, usando os passos de sempre:
adduser manuel
Originalmente, o usuário criado teria acesso completo, via SSH e SFTP. Para limitá-lo ao SFTP, abra o arquivo " /etc/passwd ", onde vai a configuração dos usuários do sistema, e procure a linha referente ao usuário criado (que normalmente será última). Originalmente você verá algo como:
manuel:x:1005:1005:,,,:/home/manuel:/bin/bash
O "/bin/bash" indica o shell ao qual o usuário terá acesso. O pulo do gato é substituir o "/bin/bash" pelo " /usr/bin/rssh ", fazendo com que ele fique restrito aos comandos scp e sftp que indicamos no arquivo "/etc/rssh.conf". Depois da alteração, a linha ficará assim:
manuel:x:1005:1005:,,,:/home/manuel:/usr/bin/rssh
