Docsity
Docsity

Prepare-se para as provas
Prepare-se para as provas

Estude fácil! Tem muito documento disponível na Docsity


Ganhe pontos para baixar
Ganhe pontos para baixar

Ganhe pontos ajudando outros esrudantes ou compre um plano Premium


Guias e Dicas
Guias e Dicas

Dominando o SSH, Notas de estudo de Engenharia Informática

O TrueTransparency é um simples programa que modifica as bordas das janelas do Windows, deixando-as estilizadas e com a transparência característica do Vista. Dessa maneira, você tem um gostinho (mas um gostinho mesmo, sem maiores benefícios) do visual do Vista.

Tipologia: Notas de estudo

Antes de 2010

Compartilhado em 23/09/2008

robson-cesar-f-leite-3
robson-cesar-f-leite-3 🇧🇷

4

(2)

4 documentos

Pré-visualização parcial do texto

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 ossh é 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 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 tux@192.168.0.1". 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 Este é um exemplo de arquivo "/etc/ssh/ssh_config" configurado com as opções que vimos até aqui (excluindo os comentários): ForwardX11 yes Compression = yes Port 22 ServerAliveInterval 120 Configuração do servidor Você pode configurar várias opções relacionadas ao servidor SSH, incluindo a porta TCP a ser usada editando o arquivo "/etc/ssh/sshd_config". A maior parte das opções dentro do arquivo podem ser omitidas, pois o servidor simplesmente utiliza valores defaults para as opções que não constarem no arquivo. Mas, de qualquer forma, é saudável especificar todas as opções que conhece: além de evitar enganos, é uma forma de praticar e memorizar as opções. - Porta: Uma das primeiras linhas é a: Port 22 Esta é a porta que será usada pelo servidor SSH. O padrão é usar a porta 22. Ao mudar a porta do servidor aqui, você deverá usar a opção "-p" ao conectar a partir dos clientes, para indicar a porta usada, como em: # ssh -p 2222 morimoto@192.168.0.1 Outra opção é editar o arquivo "/etc/ssh/ssh_config" (nos clientes) e alterar a porta padrão usada também por eles. Mudar a porta padrão do SSH é uma boa idéia se você está preocupado com a segurança. Muitos dos ataques "casuais", quando não existe um alvo definido, começam com um portscan genérico, onde é feita uma varredura em faixas inteiras de endereços IP, porém apenas em algumas portas conhecidas, como a 21, 22 e 80 (a fim de tornar o teste mais rápido, embora menos preciso). A partir daí, os ataques vão sendo refinados e direcionados apenas para os servidores vulneráveis encontrados na primeira varredura. Colocar seu servidor para escutar uma porta mais escondida, algo improvável como a porta 32456 ou 54232, já dificulta um pouco as coisas. - Controle de acesso: Logo abaixo vem a opção "ListenAddress", que permite limitar o SSH a uma única placa de rede (mesmo sem usar firewall), útil em casos de micros com duas ou mais placas. O típico caso onde você quer que o SSH fique acessível apenas na rede local, mas não na internet, por exemplo. Digamos que o servidor use o endereço "192.168.0.1" na rede local e você queira que o servidor SSH não fique disponível na internet. Você adicionaria a linha: ListenAddress 192.168.0.1 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,1 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. 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. Outras pessoas, mesmo que descubram a senha de alguma das contas, não terão como se conectar e nem como instalar uma nova chave para fazê-lo, a menos que tenham acesso físico ao servidor, a fim de copiar a chave manualmente. Isso significa que, mesmo alguém com a senha de root do seu servidor em mãos não conseguirá fazer nada remotamente (o sonho de todo administrador ;). Isso pode ser usado para incrementar a segurança. Para isso, mude as opções "ChallengeResponseAuthentication", "PasswordAuthentication" e "UsePAM" para "no" no arquivo "/etc/ssh/sshd_config" do servidor: ChallengeResponseAuthentication no PasswordAuthentication no UsePAM no Para que as alterações entrem em vigor, reinicie o servidor SSH: # /etc/init.d/ssh restart ou: # service sshd restart Bloqueando ataques de força bruta Como vimos, o SSH é um protocolo de acesso remoto muito seguro, que prevê respostas para quase todo tipo de ataque possível, de forma que o elo mais fraco da cadeia acabam sendo as senhas de acesso. Em servidores com muitos usuários, é quase impossível controlar a qualidade das senhas usadas. Embora você possa desativar o acesso a contas com senhas em branco através da opção "PermitEmptyPasswords no" no arquivo "/etc/ssh/sshd_config", pouco pode ser feito com relação a usuários que utilizam senhas fáceis ou com poucos caracteres. Existe também a possibilidade de um bot ficar testando várias possibilidades durante um longo período e, num golpe de sorte, conseguir descobrir a senha de root do servidor. O SSH impões por default um tempo de espera de dois segundos entre cada tentativa, o que torna os ataques de força bruta inefetivos, já que não é possível testar mais do que 1.800 combinações de senha por hora, mas isso não impede que um número crescente de bots fique martelando os servidos diretamente conectados e acabem descobrindo senhas de acesso em alguns deles. Uma medida simples que pode ser usada para eliminar este último risco é utilizar o fail2ban, um pequeno daemon que monitora os arquivos de log do servidor e bloqueia os endereços IP dos atacantes utilizando regras de firewall. Existem ainda os comandos "lcd" (local cd), "lls" (local ls), "lmkdir" (local mkdir) e "lpwd" (local pwd), que permitem mudar o diretório local. Por exemplo, digamos que você está atualmente no diretório "/mnt/arquivos". Ao abrir a conexão via sftp, tudo que você baixar será colocado automaticamente neste diretório. Mas, digamos que você queira baixar um determinado arquivo para o diretório "/home/joao". Você usaria, então, o comando "lcd /home/joao" para mudar o diretório 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 "lpwd" para listar os arquivos no diretório local e depois o "put arquivo" para dar upload. Naturalmente, existem meios mais práticos de fazer isso, usando programas gráficos que suportam o sftp. O mais usado, neste caso, é o konqueror. Ele possui um módulo chamado "fish://", que permite acessar servidores remotos e transferir arquivos simplesmente arrastando-os para outra janela. Acesse o endereço desejado através da própria barra de endereços, incluindo o login de acesso, como em" fish://kurumin@192.168.0.1". Você pode também especificar diretamente uma pasta no servidor remoto que quer acessar (por padrão você cai na pasta home), como em: fish://kurumin@192.168.0.1/mnt/arquivos/. Para tornar as coisas mais práticas, eu uso o recurso de dividir a janela em duas, que você encontra no Janela > Separar visão 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. 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 usuario@empresa.com.br:/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 usuario@empresa.com.br:/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/joao@64.246.47.76:/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" joao@64.246.47.76:/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/ joao@64.246.47.76:/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": 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 Em algumas distribuições (e ao instalar a partir dos fontes), o rssh será instalado dentro da pasta "/usr/local/bin" e não "/usr/bin". Preste atenção para sempre indicar a localização correta. Você pode alterar também o "/home/manuel", colocando o diretório onde ficam os arquivos que o usuário pode alterar. Se ele vai apenas alterar os arquivos de um site colocado na pasta "/var/www/manuel", por exemplo, você poderia usar: manuel:x:1005:1005:,,,:/var/www/manuel:/usr/bin/rssh Desta forma, ao conectar ele cai automaticamente na pasta correta, o que facilita as coisas. Depois de verificar tudo, teste tentando acessar localmente, usando o usuário criado: $ sftp manuel@127.0.0.1 Você notará que, via SFTP você conseguirá acessar os arquivos normalmente. Mas, ao tentar acessar via SSH, você recebe um erro, como: This account is restricted by rssh. Allowed commands: scp sftp If you believe this is in error, please contact your system administrator. Connection to 127.0.0.1 closed. Uma observação é que usando o rssh, você não conseguirá conectar usando o "fish://" do Konqueror, precisará conectar através de algum programa que use o SFTP "puro". Dois exemplos são o GFTP (no Linux) e o Filezilla (no Windows). Em ambos, procure pela opção que indica o protocolo usado e troque de "FTP" para "SSH2". Indique também a porta usada pelo servidor, que no SFTP é 22 e não 21. Quebrando arquivos Uma limitação do SSH, que afeta a transferência de arquivos via sftp, shfs, scp e até mesmo utilizando o módulo "fish://" do Konqueror é que ele permite a transferência de arquivos de até 2 GB. Em situações normais, isto não chega a ser uma grande limitação, mas em muitos casos específicos, você pode precisar copiar uma imagem de DVD, uma imagem de backup, um grande arquivo compactado ou mesmo uma máquina virtual do VMware, arquivos que passam facilmente desta marca. A solução neste caso é quebrar o arquivo em vários pedaços, de até 2 GB, transferí-los separadamente e em seguida concatená-los na sua máquina obtendo de volta o arquivo original. Você pode fazer isso facilmente usando o cat e o split, duas ferramentas básicas, que podem ser encontradas em qualquer distribuição. Para quebrar o arquivo, utilize o split, seguido da opção "-b", que permite especificar o tamanho dos pedaços, o tamanho de cada um e o arquivo que será partido: $ split -b 1000m CentOS-5.0-i386-bin-DVD.iso Isto gerará vários arquivos chamados "xaa", "xab", "xac", "xad" e assim por diante. No meu exemplo, dividi o arquivo em pedaços de 1000 MB, para facilitar a transferência, mas você pode usar pedaços maiores. Lembre-se de que 2 GB equivalem a 2048 MB e não a 2000. Depois de transferir os arquivos, use o comando cat para juntar os pedaços, gerando de volta o arquivo original: $ cat xaa xab xac xad > CentOS-5.0-i386-bin-DVD.iso Não se esqueça de verificar o md5sum do arquivo depois de transferir. Caso perceba que o arquivo foi corrompido, você pode verificar o md5sum de cada pedaço e transferir novamente apenas o pedaço que foi corrompido durante a transferência. Criando túneis seguros Uma forma simples de encriptar protocolos que em condições normais não suportam encriptação é usar o SSH para criar túneis seguros, ligando uma das portas da sua máquina à porta do servidor onde o serviço em questão está ativo. Nesse caso, é criada uma espécie de VPN temporária, através da qual é possível acessar o serviço de forma segura. Todas as informações transmitidas são encriptadas pelo SSH, tornando seguros mesmo protocolos "escancarados", como o FTP. Embora inseguro, o FTP ainda é muito usado para tarefas sensíveis, como atualizar o conteúdo de websites. O perigo é obvio: qualquer um em condições de sniffar o tráfego da rede pode capturar sua senha e usá-la para alterar o conteúdo do seu site, fazendo um acesso normal via FTP. Para evitar isso, você pode novamente usar um túnel SSH. Se você tem acesso ao servidor via SSH, pode simplesmente criar o túnel diretamente, ligando a porta 21 do servidor a uma porta da sua máquina e configurando o cliente FTP para acessar através dela. Mas, mesmo que isso não seja possível, ainda existe a possibilidade de usar qualquer outro servidor disponível na Internet, ao qual você tenha acesso via SSH para criar o túnel. Se, por exemplo, você quer acessar o servidor FTP que está escutando a porta 21 do host "meu-site.com.br", criando um túnel través do host "meu-amigo.com.br" (ao qual você tem acesso via SSH), através da porta 2121 do localhost, o comando ficaria: $ ssh -f -N -L2121:meu-site.com.br:21 -l login meu-amigo.com.br Nesse caso, é criado um túnel entre a porta 2121 da sua máquina e o host "meu- amigo.com.br", que encaminha os pacotes para a porta 21 do host "meu-site.com.br". Essa configuração é menos segura que um túnel direto, pois o túnel encriptado existe apenas entre a sua máquina e o "meu-amigo-com.br". Dele até o servidor "meu- site.com.br" é feita uma conexão normal, sem encriptação. Em teoria, os dados ainda poderiam ser capturados, mas pelo menos eles passam ilesos através da rede local, que normalmente é o ponto mais vulnerável a interceptações, sobretudo se você está acessando através de uma rede wireless sem encriptação. Para usar os túneis SSH é necessário que o servidor esteja apenas com a porta do SSH aberta no firewall. Seja qual for a porta destino, todo o tráfego é transportado através da porta do SSH e encaminhada localmente para a porta final. Graças a essa peculiaridade, os túneis são 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 túneis. Em casos em que o servidor remoto esteja configurado para usar uma porta diferente da padrão para o SSH, adicione a opção "-p porta" no início do comando, como em: $ ssh -p 2222 -f -N -L2121:meu-site.com.br:21 -l login meu-amigo.com.br SSH no Windows Existem diversas versões do SSH. A maioria das distribuições Linux inclui o OpenSSH, que não possui um cliente for Windows. No entanto, isso não chega a ser um problema, pois o SSH é um protocolo aberto, o que permite o desenvolvimento de clientes para várias plataformas, inclusive Windows. Eles são usados por muita gente para administrar servidores Linux remotamente. Um exemplo de cliente simples e gratuito é o Putty, que inclui também o PSFTP, um cliente de SFTP, que permite também transferir arquivos usando os comandos de transferência 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 não precisa sequer ser instalado. Basta baixar o arquivo e executar: O putty também permite criar túneis. Comece colocando o IP ou domínio do servidor a que vai se conectar no campo "Host Name (or IP address)" na tela principal, como se estivesse abrindo uma conexão normal. Mas, ao invés de clicar no "open", acesse a opção "Connection > SSH > Tunels". Na "source port" vai a porta do seu micro, que receberá o túnel (3128, por exemplo) e no "Destination" vai o endereço IP ou domínio do servidor remoto a que você está se conectando, seguido da porta, como em "meuservidor.com.br:3128". Clique no "Add" (você pode adicionar várias portas) e em seguida no "Open", para abrir a conexão. Na hora de transferir arquivos via SFTP, uma boa opção é o Filezilla, um cliente de FTP gráfico e bastante amigável, que inclui suporte ao SFTP. Você pode baixá-lo no: http://filezilla.sourceforge.net/ Para conectar a servidores SSH, use a opção "File > Site Manager > New Site" (os campos na tela principal servem apenas para servidores FTP). Na tela seguinte, informe o IP do servidor, a porta (22) e a conta de acesso. Uma vez conectado, você acesso 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. Sueceanhuy noomisel 5 dus ao Pe [oudaamenl=] swonking niectasy te nov fimnl/hdaB/My. Packages /HEPOSITORIO tl Elst Bancio imo tucontá [Comenaret GET coner-maçiear ceb C ttuquivo icone-rsmaçicar deb FALSE esperto Dinerladroy Jr /htaiMd Poehsge FE PENSAT AO Aces maga de) E legs Iommi de Re ge a Te) [ Fiesta Sia] /mnihda64y Packages/REFOSITORIO/ E 1 re ES | ave arquvo Des teprofaos LIES Ampvo DER ZfNafaos 2258 87 hrqueo Mi, 27/08/2006 ALE ESLISIA AQUMODEB AZNMÍZMOS 2256 Eliuruno-painet det 87 devo a7joapmas LIS +58 Membros 17inÍzaos 2256 SO Arquivo NOOs 2258 al 1 a J 2» seo This PDF was created using the Sonic PDF Creator. To remove this watermark, please license this product at wyw.investintech.com
Docsity logo



Copyright © 2024 Ladybird Srl - Via Leonardo da Vinci 16, 10126, Torino, Italy - VAT 10816460017 - All rights reserved