sexta-feira, 25 de fevereiro de 2011

Tutorial completo Ubuntu Server Como Roteador, Samba e SSH Para Iniciantes.

Olar Pessoal Meu nome é: Luciano sou Gerênte de Redes da Winfox ha 15 Anos e vou passar um pouco dos meus conhecimentos ai pra vcs, Como vcs estão vendo o meu blogger é novo ainda não divulguei, E espero que vcs possam aproveitar ai o maximo o conteudo que postei depois de muito trabalho que tive ai na net com pesquisas livros olhei bastante muito tutorial e o mais simplificado que pude chegar foi esse ai espero que vcs aproveite bastante especialmente os amigos ai que tão começando agora no linux, Bons Estudos a Todos e Vamos Lá...

Introdução
Quando as conexões de banda larga começaram a se tornar populares, por volta de 2000, compartilhar a conexão se tornou uma dúvida comum, já que compartilhar uma conexão ininterrupta faz muito mais sentido do que compartilhar a conexão via modem. No começo, era muito comum serem usados PCs com o Windows 98 ou 2000, compartilhando a conexão através do ICS, ou micros antigos rodando mini-distribuições Linux especializadas na tarefa, como o antigo Coyote.
Hoje em dia, compartilhar a conexão deixou de ser um problema, já que praticamente qualquer modem ADSL pode ser configurado como roteador, sem falar dos pontos de acesso com funções de roteador e da enorme variedade de servidores domésticos que temos no mercado.
Vamos então a um tutorial rápido de como compartilhar a conexão no Linux, usando um PC com duas placas de rede, aproveitando para incluir também alguns recursos adicionais no servidor, instalando também um proxy transparente e um servidor DHCP. Este mesmo servidor pode ser configurado também como um servidor de arquivos e impressoras para a rede, assumindo também o papel de NAS.
Os passos a seguir podem ser usados em praticamente qualquer distribuição, de forma que você pode usar a que tiver mais familiaridade. Também não é necessário reservar um PC só para compartilhar a conexão: você pode perfeitamente usar seu próprio micro, ou outro que fique ligado continuamente.
Se você não se importar em fazer a configuração via linha de comando, você pode utilizar um PC antigo, instalando a versão server do Ubuntu. Ela está disponível no http://www.ubuntu.com/getubuntu/downloadmirrors, juntamente com a versão principal, mas é um pouco menor, com cerca de 500 MB.
Ao contrário da versão desktop, que carrega o ambiente gráfico por padrão e precisa de um PC com pelo menos 256 MB de memória RAM para rodar, a versão server usa um instalador simples, em modo texto (o mesmo usado nas primeiras versões), e pode ser instalada mesmo em micros com apenas 32 MB de memória RAM: Esta versão instala apenas os pacotes básicos, sem o ambiente gráfico, por isso o boot depois da instalação é feito em modo texto. Logue-se usando a conta criada durante a instalação e use o comando "sudo passwd" para definir a senha de root. A partir daí você pode se logar diretamente como root, como em outras distribuições:
$ sudo passwd
Inicialmente, o Ubuntu server vem apenas com o vi instalado, que não é um editor de texto particularmente amigável, mas, depois de fazer a configuração inicial da rede (editando o arquivo "/etc/network/interfaces"), você pode instalar outro editor mais amigável, como o mcedit (que faz parte do pacote "mc"), o "joe" ou o "nano". Não importa muito qual editor resolva usar, o importante é que você se sinta confortável com pelo menos um deles.
Um exemplo de arquivo "/etc/network/interfaces" configurado é:
# /etc/network/interfaces
auto lo eth0
iface lo inet loopback
iface eth0 inet static
address 192.168.1.2
netmask 255.255.255.0
network 192.168.1.0
broadcast 192.168.1.255
gateway 192.168.1.1

O arquivo é dividido em duas partes. A linha "auto ..." lista as interfaces que devem ser ativadas automaticamente e as demais contém a configuração de cada uma. Para configurar uma nova placa de rede, você adicionaria a configuração relacionada a ela no final do arquivo e a adicionaria na linha "auto", como em "auto lo eth0 eth1". Se, por outro lado, você quiser desativar uma interface, precisa apenas removê-la da linha auto, não é preciso remover as demais linhas.
A interface "lo" é a interface de loopback, usada para a comunicação local entre diversos aplicativos e componentes do sistema, por isso nunca deve ser desativada. Embora o uso da interface de loopback pareça ser uma exclusividade do Linux, ela é usada também no Windows; a única diferença é que no Windows ela não aparece na configuração.
Em seguida temos a configuração de cada interface, que vai em uma seção separada. No caso da interface lo é usada uma única linha, "iface lo inet loopback", usada em qualquer instalação, seguida pelas demais interfaces.
Como você pode ver, as últimas 5 linhas na configuração da placa eth0 especificam o IP utilizado pelo PC e o restante da configuração da rede, com exceção dos endereços dos servidores DNS, que vão no arquivo "/etc/resolv.conf".
Se você quisesse que a interface fosse configurada via DHCP, poderia substituir as 6 linhas referentes a ela por:
iface eth0 inet dhcp

Ao configurar um servidor com duas placas de rede, onde a eth0 está ligada à rede local e a eth1 ao cable modem (obtendo o endereço via DHCP), por exemplo, o arquivo ficaria:
# /etc/network/interfaces
auto lo eth0 eth1
iface lo inet loopback
iface eth0 inet static
address 192.168.1.1
netmask 255.255.255.0
network 192.168.1.0
broadcast 192.168.1.255
iface eth1 inet dhcp

Veja que nesse caso a configuração da interface eth0 não inclui o gateway, pois é a eth1 que será usada para acessar a web.
Depois de editar o arquivo, você pode aplicar as alterações reiniciando o serviço relacionado a ele:
# /etc/init.d/networking restart

Um problema comum que afeta versões do Debian, Ubuntu e distribuições baseadas neles é as interfaces mudarem de endereço a cada reset em micros com duas ou mais interfaces de rede. A placa eth0 passa então a ser a ath1 e assim por diante, o pode ser uma grande dor de cabeça ao configurar um servidor para compartilhar a conexão, já que se as duas interfaces mudam de posição, nada funciona.
A solução para o problema é um pequeno utilitário chamado "ifrename", que permite fixar os devices utilizados para as placas. Utilizá-lo é bem simples. Comece instalando o pacote via apt-get:
# apt-get install ifrename

Crie o arquivo "/etc/iftab" e, dentro dele, relacione o device de cada interface com o endereço MAC correspondente, seguindo o modelo abaixo:
#/etc/iftab
eth0 mac 00:11:D8:76:59:2E
eth1 mac 00:E0:7D:9B:F8:01

Em caso de dúvida, use o comando "ifconfig -a" para ver a configuração atual das placas e o endereço MAC de cada uma. Uma vez criado, o arquivo é verificado a cada boot e a configuração se torna persistente, resolvendo o problema. Este bug das interfaces itinerantes afeta apenas algumas distribuições, por isso você não precisa se preocupar com ele até que perceba que está usando uma das afetadas.
O Ubuntu server vem com o servidor SSH instalado por padrão, de forma que depois de configurar a rede, você pode fazer todo o resto da configuração confortavelmente a partir do seu micro. Uma dica é que ao utilizar o joe, o nano ou o vi (o mcedit não suporta o uso do clipboard), você pode usar o botão central do mouse para colar texto dentro do terminal, o que é muito útil quando você tem um modelo de configuração pronto pra usar.
Depois de configuradas as duas interfaces de rede, ativar o compartilhamento da conexão é bastante simples. No Linux o trabalho é feito pelo iptables, o firewall padrão do sistema, que incorpora a função de compartilhamento através do módulo "iptable_nat". Para ativar o compartilhamento, precisamos apenas carregar o módulo, ativar o roteamento de pacotes e em seguida executar o comando que ativa o compartilhamento propriamente dito. Explicando assim pode parecer difícil, mas na prática isso é feito usando apenas 3 comandos:
# modprobe iptable_nat
# echo 1 > /proc/sys/net/ipv4/ip_forward
# iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

O "eth0" no terceiro comando indica a placa onde está a conexão com a Internet. Não se esqueça de indicar a interface apropriada ao executar o comando (na dúvida você pode checar a configuração da rede usando o ifconfig). Se você acessa via ADSL, usando o pppoeconf ou o adsl-setup (com o modem configurado como bridge) será criada a interface "ppp0".
A partir daí, todas as requisições recebidas na interface de rede local serão mascaradas e roteadas usando a interface especificada e as respostas serão devolvidas aos PCs da rede local.
É possível compartilhar qualquer tipo de conexão, incluindo conexões discadas, wireless, conexões via celular e assim por diante. O servidor simplesmente passa a rotear os pacotes dos demais micros da rede, transmitindo todas as requisições através da conexão que possui. Você precisa apenas configurar os demais PCs da rede para o utilizarem como gateway.
Nem todas as distribuições instalam o executável do iptables por padrão. No Mandriva, por exemplo, ele é instalado ao marcar a categoria "firewall" durante a instalação. Para instalá-lo posteriormente, use o comando "urpmi iptables".
Os três comandos devem ser colocados em algum dos arquivos de inicialização do sistema para que passem a ser executados automaticamente durante o boot. No caso do Ubuntu e outras distribuições derivadas do Debian, você pode utilizar o arquivo "/etc/rc.local". No Fedora, Mandriva e outras distribuições derivadas do Red Hat, use o arquivo "/etc/rc.d/rc.local".
Você pode aproveitar para proteger o servidor usando um firewall simples, que bloqueie as portas de entrada, deixando passar apenas pacotes de respostas e conexões em portas indicadas manualmente. Com isso, o firewall garante um bom nível de proteção, com um mínimo de efeitos colaterais.
Para isso, utilizaremos o próprio iptables, complementando os três comandos anteriores. Estes comandos podem ser incluídos no arquivo /etc/rc.local ou /etc/rc.d/rc.local, logo abaixo dos comandos para compartilhar a conexão:
iptables -A INPUT -p icmp --icmp-type echo-request -j DROP
echo 1 > /proc/sys/net/ipv4/conf/default/rp_filter
iptables -A INPUT -m state --state INVALID -j DROP
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -i eth1 -j ACCEPT
iptables -A INPUT -p tcp --syn -j DROP

O primeiro comando faz com que o seu servidor deixe de responder a pings. Muitos ataques casuais começam com uma varredura de diversas faixas de endereços de conexões domésticas, enviando um ping para todas as máquinas. Responder ao ping indica não apenas que a máquina está online, mas também que provavelmente ela está com o firewall desativado, o que estimula o atacante a continuar o ataque, lançando um portscan e iniciando o ataque propriamente dito. Deixando de responder aos pings, o volume de ataques ao servidor cai bastante.
Os dois comandos seguintes protegem contra IP spoofing (uma técnica usada em diversos tipos de ataques, onde o atacante envia pacotes usando um endereço IP falseado como remetente, tentando assim obter acesso a PCs da rede interna) e contra pacotes inválidos, que são comumente utilizados em ataques DoS e ataques de buffer overflow.
As três últimas linhas autorizam pacotes provenientes da interface de loopback (lo), juntamente com pacotes provenientes da rede local e descartam novas conexões na interface de Internet, deixando passar apenas pacotes de resposta. Não se esqueça de substituir o "eth1" pela interface de rede local correta, caso contrário você vai acabar fazendo o oposto, ou seja, bloqueando as conexões dos PCs da rede local e deixando passar as provenientes da Internet :).
Se você quiser abrir portas específicas adicione a regra "iptables -A INPUT -p tcp --dport 22 -j ACCEPT" (onde o "22" é a porta e o "tcp" é o protocolo) antes da regra que bloqueia as conexões. Você pode repetir a regra caso necessário, abrindo assim todas as portas desejadas.
No final, incluindo os comandos para compartilhar a conexão e regras para abrir as portas 22 (SSH) e 6881 (bittorrent), os comandos a adicionar no script de inicialização seriam:
#!/bin/sh
# Compartilha a conexão
modprobe iptable_nat
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
# Bloqueia pings e protege contra IP spoofing e pacotes inválidos
iptables -A INPUT -p icmp --icmp-type echo-request -j DROP
echo 1 > /proc/sys/net/ipv4/conf/default/rp_filter
iptables -A INPUT -m state --state INVALID -j DROP
# Abre para a interface de loopback e para a interface de rede local
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -i eth1 -j ACCEPT
# Abre para as portas especificadas
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
iptables -A INPUT -p tcp --dport 6881 -j ACCEPT
# Bloqueia as demais conexões, deixando passar apenas pacotes de resposta
iptables -A INPUT -p tcp --syn -j DROP

Você pode também criar um filtro simples de conteúdo indicando manualmente endereços que devem ser bloqueados, usando o comando "iptables -A FORWARD -d dominio.com -j DROP". Isso faz com que o servidor se recurse a encaminhar pacotes destinados aos endereços citados, impedindo que eles sejam acessados a partir dos micros da rede local. Você só precisa adicionar uma regra para cada domínio a ser bloqueado no seu script de firewall, como em:
iptables -A FORWARD -d orkut.com -j DROP
iptables -A FORWARD -d msn.com -j DROP
iptables -A FORWARD -d myspace.com -j DROP

Usada dessa forma, a regra bloqueia o acesso aos domínios especificados usando qualquer protocolo. Ou seja, se você adicionar uma regra bloqueando um tracker bittorrent, por exemplo, os clientes bittorrent rodando nas máquinas da rede não conseguirão se conectar a ele para fazerem download dos arquivos. Praticamente qualquer programa que precise se conectar a um servidor central, com um endereço fixo, pode ser bloqueado usando esta regra, desde que você saiba indicar o endereço correto.
A limitação é que esta regra se aplica apenas ao servidor relacionado ao domínio, por isso ela não bloqueia subdomínios hospedados em servidores diferentes. Por exemplo, você pode bloquear o domínio "uol.com.br", mas isso não bloqueará o "tvuol.uol.com.br", que é hospedado em um servidor separado. Em casos como este, a única solução é bloquear ambos.
Outra dica é que, ao compartilhar uma conexão discada ou uma conexão via celular (que também é uma forma de conexão discada, já que você precisa usar o kppp ou o gnome-ppp), você pode fazer com que o sistema execute o script de compartilhamento ao efetuar a conexão usando a aba "Executar" nas propriedades da conexão.
Adapte o script de compartilhamento para compartilhar a interface ppp0 e coloque o comando que executa o script no campo "Ao conectar":

Com isso o compartilhamento é automaticamente ativado ao conectar. A principal observação é que para usar o script de compartilhamento dessa forma você deve abrir o kppp como root, ou modificar o script de forma que ele use o sudo em todos o comandos que precisarem ser executados como root, de forma que ele possa ser executado usando seu login de usuário.
Os servidores proxy são a forma mais antiga de compartilhar a conexão entre vários micros. Diferente de um servidor configurado para compartilhar a conexão via NAT, que simplesmente roteia pacotes da rede local para a Internet e da Internet para a rede local, mascarando os endereços, um servidor proxy oferece um acesso mais limitado, intermediando a conexão, vasculhando o conteúdo dos pacotes e permitindo apenas o acesso a portas específicas. A grande desvantagem é que todos os micros da rede precisam ser configurados manualmente para utilizarem o proxy.
Usar um servidor proxy permite logar os acessos, impor restrições diversas, baseadas em horários, endereços e outras condições, limitar o uso de banda e assim por diante, o que faz com que eles sejam bastante populares em redes empresariais, onde a redução no uso da banda e o possível aumento na produtividade compensam o trabalho necessário.
Em uma rede doméstica, você pode configurar o servidor proxy para trabalhar em modo transparente, onde ele passa a fazer seu trabalho de forma invisível, sem que você precise configurar os micros da rede para utilizarem-no. O proxy complementa então o compartilhamento via NAT, cacheando os arquivos e as páginas acessadas.
O servidor passa então a armazenar atualizações do Windows Update, downloads diversos, páginas e imagens, pacotes instalados através do apt-get e tudo mais que for acessado via http. Com isso, muita coisa passará a ser acessada a partir do cache do servidor proxy, reduzindo o uso de banda e agilizando o acesso.
A principal limitação é que o proxy transparente irá cachear apenas o tráfego http, através da porta 80. Não é possível usar um proxy transparente para FTP e SSL, a menos que você configure os programas em cada PC manualmente para utilizarem o proxy. No Firefox por exemplo, a configuração de proxy vai dentro do menu "Editar > Preferências", em "Rede > Configurações > Configuração manual de proxy":
Marcando a opção "Usar este proxy para todos os protocolos" você faz com que todo o tráfego passe pelo proxy e seja armazenado no cache, incluindo os arquivos baixados via FTP e https. O problema é que você precisaria fazer essa configuração em todos os micros da rede, o que anula a principal vantagem de usar um proxy transparente, que é a possibilidade de ter ganhos na velocidade de acesso sem precisar fazer modificações nos PCs da rede.
De qualquer forma, a configuração que utilizaremos atende tanto aos PCs configurados para acessar a web diretamente quanto aos PCs configurados manualmente para usar o proxy, de forma que a configuração dos clientes fica a seu critério.
O primeiro passo é configurar o servidor Linux com duas placas de rede para compartilhar a conexão, como vimos nos tópicos anteriores. O proxy transparente é apenas um add-on, que complementa o compartilhamento da conexão via NAT.
Com tudo funcionando, o próximo passo é instalar o Squid, o que é feito através da instalação do pacote "squid" usando o gerenciador de pacotes, como em:
# apt-get install squid

ou:
# yum install squid

A configuração do Squid é feita através de um único arquivo, o "/etc/squid/squid.conf". O arquivo de exemplo, instalado junto com o pacote é assustadoramente grande, com mais de 3000 linhas, incluindo comentários sobre todas as opções disponíveis. Ele é uma boa leitura se você quiser se aprofundar na configuração do Squid, mas se você quer apenas ver seu proxy transparente funcionando, é mais fácil renomear o arquivo e começar com um arquivo de configuração vazio:
# mv /etc/squid/squid.conf /etc/squid/squid.conf.modelo
# touch /etc/squid/squid.conf

Abra o arquivo /etc/squid/squid.conf em branco que foi criado e copie o modelo de configuração abaixo. As opções em negrito são as opções que você precisa alterar:
# /etc/squid/squid.conf
http_port 3128 transparent
visible_hostname gdh
cache_mem 64 MB
maximum_object_size_in_memory 128 KB
maximum_object_size 512 MB
cache_dir ufs /var/spool/squid 4096 16 256
cache_access_log /var/log/squid/access.log
acl all src 0.0.0.0/0.0.0.0
acl manager proto cache_object
acl localhost src 127.0.0.1/255.255.255.255
acl SSL_ports port 443 563
acl Safe_ports port 80 21 280 443 488 563 591 777 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
acl redelocal src 192.168.1.0/24http_access allow localhost
http_access allow redelocal
http_access deny all

A primeira linha indica a porta utilizada pelo Squid (3128) e que ele deve operar em modo transparente (transparent). A segunda indica o nome do servidor (gdh), que você deve substituir pelo nome do seu.
As quatro linhas seguintes indicam a configuração do cache. O Squid trabalha com dois caches distintos, um cache mais rápido, feito na memória RAM, e outro mais lento (porém maior) feito usando espaço do HD.
O "cache_mem 64 MB" indica o tamanho do cache na memória RAM (é recomendável que você utilize no máximo 1/3 da memória total instalada), enquanto o "4096" na linha cache_dir ufs /var/spool/squid 4096 16 256" indica o tamanho do cache que será feito no HD, em megabytes.
A linha "acl redelocal src 192.168.1.0/24" indica a faixa de endereços e a máscara utilizada na sua rede local (o /24 equivale à mascara 255.255.255.0). Combinada com as regras "http_access allow redelocal" e "http_access deny all" ela faz com que apenas micros da rede local possam utilizar o proxy, afastando qualquer possibilidade de que ele fique aberto para a Internet, independentemente da configuração do firewall.
A linha maximum_object_size 512 MB indica o tamanho máximo de arquivo que será armazenado no cache (arquivos maiores do que isso serão ignorados), o que evita que arquivos muito grandes, (como imagens ISO) que você vai baixar apenas uma vez, desperdicem espaço no cache.
Depois de terminar, reinicie o Squid para que a configuração entre em vigor:
# /etc/init.d/squid restart

Com isso, a configuração do servidor proxy está pronta, mas falta um passo igualmente importante, que é ativar a regra de firewall que faz com que os acessos destinados à porta 80, provenientes da rede local sejam encaminhados para o Squid. Sem isso, as requisições continuam sendo roteadas diretamente, sem passarem pelo proxy:
# iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 80 -j REDIRECT --to-port 3128

Note que o "eth1" no comando especifica a interface de rede local, que deve ser alterada de acordo com a sua configuração. Este comando deve ser colocado no script de inicialização (juntamente com os comandos para compartilhar a conexão) para que seja executado automaticamente durante o boot.
Depois de ativar a regra de firewall, você pode testar o proxy navegando em algum dos micros da rede local (que use o servidor como gateway) e verificar o conteúdo do arquivo "/var/log/squid/access.log" no servidor. Conforme as requisições passam pelo proxy, o arquivo é alimentado com um grande volume de informações sobre as conexões realizadas, como em:
1201780615.239 1337 192.168.1.10 TCP_MISS/302 884 GET http://192.168.112.2o7.net/b/ss/mxmacromedia/1/F.3-XELvs - DIRECT/216.52.17.136 text/plain
1201780615.753 248 192.168.1.10 TCP_MISS/200 1526 GET http://wwwimages.adobe.com/www.adobe.com/lib/com.adobe/template/gnav/google.gif - DIRECT/204.245.162.8 image/gif
1201780647.918 29013 192.168.1.10 TCP_MISS/200 3036521 GET http://fpdownload.macromedia.com/get/flashplayer/current/install_flash_player_9_linux.tar.gz - DIRECT/72.246.38.70 application/x-gzip

Pela presença das entradas no arquivo você percebe que os acessos estão realmente passando pelo proxy.
Uma última observação é que esta configuração vale para as versões recentes do Squid, do 2.6 em diante. Em versões antigas do Squid eram usadas 4 linhas adicionais no final do arquivo, no lugar do parâmetro "transparent" na primeira linha:
httpd_accel_host virtual
httpd_accel_port 80
httpd_accel_with_proxy on
httpd_accel_uses_host_header on

A menos que você esteja usando o Debian Sarge, ou outra distribuição antiga, é improvável que esteja usando uma versão do Squid anterior à 2.6. De qualquer forma, fica a observação. A maior parte dos tutoriais disponíveis na web são anteriores à mudança e por isso ensinam a usar esta configuração antiga, que não funciona mais nas versões atuais. Em caso de dúvida, você pode checar a versão do Squid instalada usando o comando "squid -v".

Complementando o compartilhamento da conexão, você pode configurar também um servidor DHCP, especificando a configuração que deve ser fornecida aos PCs da rede. É importante enfatizar que você deve manter apenas um servidor DHCP ativo na rede, de forma que se você já está usando o servidor DHCP do modem ou do roteador wireless, você deve primeiro desativá-lo, antes de ativar o DHCP no servidor.
Com dois servidores DHCP na rede, ambos irão responder às requisições e as máquinas vão simplesmente usar a configuração que receberem primeiro. Mesmo que ambos os servidores DHCP estejam configurados para fornecer a configuração correta, você poderá ter problemas com máquinas recebendo endereços repetidos (um servidor DHCP não tem como saber quais foram os endereços fornecidos pelo outro) e assim por diante. Confie em mim, manter um único servidor DHCP ativo vai tornar sua vida bem mais simples. :)
Para instalar o servidor DHCP, instale o pacote "dhcp3-server" usando o gerenciador de pacotes, como em:
# apt-get install dhcp3-server

No Fedora o pacote se chama "dhcp" e no Mandriva se chama "dhcpd". Você pode instalá-lo usando (respectivamente) os comandos:
# yum install dhcp
# urpmi dhcpd

Nas distribuições derivadas do Debian o arquivo de configuração é o "/etc/dhcp3/dhcpd.conf" e no Fedora e Mandriva é o "/etc/dhcpd.conf". Apesar disso, em ambos os casos a configuração é a mesma.
Você pode usar o modelo de configuração abaixo. Assim como no caso do Squid, as opções em negrito são as que você deve alterar de acordo com a configuração da sua rede:
# dhcpd.conf
ddns-update-style none;
default-lease-time 600;
max-lease-time 7200;
authoritative;
subnet 192.168.1.0 netmask 255.255.255.0 {
range 192.168.1.100 192.168.1.250;
option routers 192.168.1.1;
option domain-name-servers 208.67.222.222,208.67.220.220;
option broadcast-address 192.168.1.255;
}

A opção "default-lease-time" controla o tempo de renovação dos endereços IP. O servidor DHCP checa periodicamente se a estação ainda está ativa e, ao perceber que ela foi desligada ou desconectada da rede, libera o endereço para uso de outro micro, evitando que os endereços disponíveis se esgotem. O "default-lease-time" indica o intervalo entre as checagens e o "max-lease-time" determina o tempo máximo antes de liberar o endereço. Em condições normais, essas duas opções não são muito importantes. O que interessa mesmo é o bloco que vai abaixo, onde ficam as configurações da rede.
A opção "range" determina a faixa de endereços IP que será usada pelo servidor. No exemplo, configurei o DHCP para fornecer os endereços de 192.168.1.100 a 192.168.1.250, de forma a ficar com os demais endereços livres para o uso em estações com IP fixo, mas você poderia reservar toda a faixa de endereços da rede para o DHCP (deixando de fora apenas o endereço do gateway), como em "range 192.168.1.2 192.168.1.254;".
Na "option routers" vai o endereço do default gateway da rede, ou seja, o endereço do servidor que está compartilhando a conexão, enquanto a opção "option domain-name-servers" contém os dois servidores DNS que serão usados pelas estações, separados por vírgula.
O endereço de broadcast é sempre o último endereço da rede, como em "192.168.1.255" ou "10.255.255.255". Ele simplesmente acompanha a faixa de endereços e a máscara utilizada.
Depois de terminada a configuração, reinicie o servidor DHCP para que ela entre em vigor:
# /etc/init.d/dhcp3-server restart

(no Debian e derivados) ou:
# service dhcp restart

(no Fedora e Mandriva)
Ao configurar um servidor com duas placas de rede no Ubuntu ou outra distribuição derivada do Debian, abra o arquivo "/etc/default/dhcp3-server" e indique qual é a placa da rede local, como em:
INTERFACES="eth0"
Isso faz com que o servidor forneça endereços apenas para micros ligados à interface indicada e não mais em qualquer uma das interfaces. Isso evita que ele responda a conexões provenientes da Internet.
Se você quiser também que o servidor atue como um servidor DNS, instale também o pacote "bind", como em:
# apt-get install bind

Ao contrário do DHCP, ele não precisa de configuração, pois vem de fábrica configurado para trabalhar como um servidor DNS de cache, que simplesmente repassa as requisições para um dos 13 root servers da Internet e faz um cache das respostas.
Como vimos no capítulo 2, um servidor DNS local será geralmente mais lento, mas é interessante ter um para testar problemas de conectividade. Afinal, se você consegue navegar usando seu DNS local, mas não navega usando o DNS do provedor, significa que a conexão está funcionando e o problema é apenas no DNS.
Servidor de Arquivo Para rede Local
Servidor de Arquivo no Linux
Como vimos no tutorial sobre configuração de redes Windows, compartilhar arquivos no Windows XP é bastante simples. Em resumo, você precisa ativar o "Cliente para redes Microsoft" e o "Compartilhamento de arquivos e impressoras para redes Microsoft" nas propriedades da conexão local e, a partir daí, compartilhar as pastas desejadas através do Windows Explorer. O XP usa o simple sharing por padrão, o que permite que todos os usuários da rede tenham acesso aos compartilhamentos, sem que você precise cadastrar logins de acesso para cada um.
Vamos ver agora como fazer o mesmo usando um pequeno servidor Linux, rodando o Samba. O objetivo do servidor é compartilhar arquivos e impressoras com a rede local de uma forma simples, funcionando como uma espécie de NAS. Você pode tanto fazer esta configuração na sua própria máquina, ou em outro desktop da rede, quanto usar alguma máquina antiga, dedicada à tarefa. Os passos podem ser seguidos na grande maioria das distribuições.
O primeiro passo é instalar o servidor Samba, o que é feito instalando o pacote "samba" usando o gerenciador de pacotes. No Ubuntu ou Debian você usaria o apt-get (apt-get install samba), no Fedora usaria o yum (yum install samba), no Mandriva usaria o urpmi (urpmi samba) e assim por diante.
Muitos preferem configurar o Samba usando o swat, mas com tantas opções ele seria overkill no nosso caso e só iria atrapalhar. Ao invés dele, vamos a uma lista de passos rápidos para configurar o servidor via terminal.
Comece logando-se como root no terminal usando o comando "su -". No caso do Ubuntu você precisa primeiro definir uma senha para o root, usando o comando "sudo passwd".
$ su -
O primeiro passo para configurar o Samba é cadastrar pelo menos uma conta de usuário, usando o comando "smbpasswd -a". Isso é necessário para que o Samba possa autenticar os usuários remotos e possa ler os arquivos dentro das pastas compartilhadas. Apesar de rodar como um serviço, o Samba está subordinado às permissões de acesso do sistema.
Você pode adicionar a sua própria conta de usuário, como em:
# smbpasswd -a gdh
New SMB password:
Retype new SMB password:
Se preferir, você pode também criar uma nova conta, exclusiva para uso do Samba, como em:
# adduser joao
# smbpasswd -a joao
Normalmente, você precisaria cadastrar várias contas de usuário e distribuir as senhas entre todos que fossem acessar os compartilhamentos. Entretanto, é possível fazer uma configuração mais simples usando uma conta guest. Esta configuração permite que os usuários da rede local acessem os compartilhamentos sem precisarem de um login válido, algo similar ao simple sharing do Windows XP. Não é o tipo de configuração que você usaria em uma grande rede, mas é muito prático para usar em uma pequena rede, onde você conhece todo mundo e simplesmente quer compartilhar os arquivos de uma forma simples.
Depois de cadastrar o usuário, falta configurar o Samba, o que é feito editando o arquivo "/etc/samba/smb.conf". Você pode editá-lo usando o editor que preferir, como em:
# mcedit /etc/samba/smb.conf
ou
# gedit /etc/samba/smb.conf
Muitas distribuições vem configuradas por padrão para não executarem aplicativos gráficos quando você está logado como root no terminal. Ao tentar rodar o programa, você recebe um erro "cannot open display"
Nesses casos, você tem duas opções:
a) Logar-se como root usando o comando "sux" no lugar do "su -", ele ajusta as permissões necessárias, eliminando o problema. Ele é instalado através do pacote de mesmo nome.
b) Usar o sudo para abrir o programa, como em "sudo gedit /etc/samba/smb.conf", nesse caso executando o comando o comando com seu login de usuário e confirmando a sua senha, quando solicitado.
Voltando à edição do arquivo, apague todo o conteúdo do arquivo, deixando-o com o seguinte conteúdo:
[global]
netbios name = Sparta
server string = Servidor Samba
workgroup = Grupo
local master = yes
os level = 100
preferred master = yes
wins support = yes

printing = cups
load printers = yes

map to guest = bad user
guest account = gdh

[printers]
comment = Impressoras
print ok = yes
guest ok = yes
path = /var/spool/samba

[arquivos]
path = /media/hda3/arquivos
writable = yes
guest ok = yes
[videos]
path = /home/gdh/videos
writable = yes
guest ok = yes
As opções a alterar são:
netbios name: Indica o nome do servidor, com o qual ele aparecerá no ambiente de rede.
workgroup: O grupo de trabalho, o mesmo especificado na configuração das outras máquinas da rede.
guest account: Aqui você especifica a conta que cadastramos anteriormente usando o comando "smbpasswd -a".
Os compartilhamentos do Samba seguem uma estrutura muito simples, onde você indica o nome do compartilhamento (da forma como ele aparecerá no ambiente de rede) entre chaves e indica a pasta a que ele dará acesso na opção "path". A opção "writable = yes" faz com que o compartilhamento seja para leitura e escrita e a "guest ok = yes" faz com que ele fique disponível para qualquer usuário da rede, já que qualquer tentativa de acesso com um login de usuário que não existe será mapeada para o usuário "gdh".Você pode criar mais compartilhamentos usando este mesmo modelo, mudando apenas o nome e a pasta a compartilhar. Com esta configuração, o servidor irá também compartilhar as impressoras instaladas automaticamente, você precisará apenas fornecer os drivers de impressão ao instalá-las nos clientes.
O único cuidado é que o usuário usado na opção "guest account" (o gdh no exemplo) precisa ter acesso completo ao conteúdo das pastas compartilhadas, já que todos os acessos serão feitos através dele. Caso necessário, altere as permissões de acesso às pastas, usando o comando "chown -R", como em:
# chown -R gdh.gdh /media/hda3/arquivos
O "-R" no comando faz com que as alterações seja aplicadas de forma recursiva, atingindo todos os subdiretórios dentro da pasta, enquanto o "gdh.gdh" indica o usuário e o grupo que assumirá o controle.
Uma última observação é que este arquivo de configuração faz com que seu servidor Samba assuma a função de master browser da rede, fornecendo aos clientes a lista dos compartilhamentos disponíveis em toda a rede. Se você for usar esta configuração em mais de um servidor na mesma rede, remova a linha "local master = yes", ou use um número mais baixo na opção "os level =" (nos demais servidores), caso contrário os servidores ficarão continuamente disputando o cargo, o que prejudicará a navegação dos clientes.
As alterações feitas no arquivo de configuração do Samba são aplicadas automaticamente após alguns minutos, mas se você quiser verificar rapidamente uma alteração que acabou de fazer, pode forçar o reinicio do servidor usando o comando:
# /etc/init.d/samba restart
(ou /etc/init.d/smb restart, no Fedora e no Mandriva)
Os arquivos dentro dos compartilhamentos podem ser acessados usando o ambiente de redes nos clientes Windows ou clientes como o Smb4K nos clientes Linux. Mas, se você pretender manter o servidor ligado continuamente, o ideal é mapear os compartilhamentos, de forma que eles fiquem acessíveis permanentemente e a conexão seja restaurada durante o login.
Nos clientes Windows, você pode mapear compartilhamentos clicando com o botão direito sobre o "Meu Computador" e usando a opção "Mapear unidade de rede".
Nos clientes Linux, a melhor opção para criar um mapeamento permanente é inserir uma linha diretamente no arquivo "/etc/fstab", que contém a lista das partições e compartilhamentos de rede que o sistema deve montar durante o boot.
O arquivo "/etc/fstab" é um dos principais arquivos de inicialização do sistema e por isso deve ser sempre editado com cuidado. Adicione apenas a nova linha, sem alterar as demais, tomando o cuidado de deixar uma linha em branco no final do arquivo. A linha segue o seguinte modelo:
//servidor/arquivos /mnt/smb smbfs username=gdh,password=1234,uid=joao 0 0
O "//servidor/arquivos" é o caminho para o compartilhamento na rede, incluindo o endereço IP ou nome do servidor e o nome do compartilhamento que será montado, o "mnt/smb" é a pasta local onde ele será montado, o "smbfs" indica o sistema de arquivos, o "username=gdh,password=1234" indica o login e senha que serão usados para acessar o servidor, o "uid=joao" indica o usuário local (no cliente Linux) que terá acesso completo aos arquivos dentro da pasta montada, enquanto o "0 0" é um "nada a declarar", que indica que não temos opções adicionais.
Dentro do nosso exemplo, poderíamos usar a linha:
//192.168.1.254/videos /media/videos smbfs username=fulano,password=1234,uid=gdhnet 0 0
Veja que, por segurança, preferi especificar diretamente o endereço IP do servidor, de forma a evitar qualquer possibilidade de problemas relacionado à resolução do nome. Como nosso servidor foi configurado para permitir o acesso usando a conta guest, posso colocar qualquer login na opção "username=" e qualquer senha na "password=". O "gdhnet" indica a conta que uso no cliente Linux, com a qual vou acessar a pasta onde o compartilhamento será montado.
Para que a alteração entre em vigor sem precisar reiniciar o micro, use o comando "mount -a" (no cliente), como root.
Com o compartilhamento montado, você pode acessar os arquivos da mesma forma que acessaria uma partição local, inclusive abrindo arquivos e vídeo e audio sem precisar copiá-los para a sua máquina previamente. A única observação é que a banda da rede precisa ser suficiente para transferir o arquivo na velocidade necessária para exibí-lo, de forma que assistir um vídeo em alta resolução, através de uma rede wireless lenta ou congestionada pode resultar em um vídeo saltado.
SSH Para Iniciante
Introdução
O SSH é uma ferramenta de acesso remoto bastante poderosa, que permite acessar máquinas Linux remotamente de forma segura. Ele se baseia no uso de criptografia assimétrica para criar um túnel seguro onde são transmitidos os dados, garantindo a segurança mesmo em casos onde a transmissão pode ser interceptada, como no caso de uma rede wireless sem encriptação.
As chaves assimétricas são um sistema muito interessante, onde temos um par de chaves em vez de uma única chave simétrica. Uma (a chave pública), permite apenas encriptar dados, enquanto a segunda (a chave privada) permite desencriptar as informações embaralhadas pela primeira. O grande segredo é que qualquer informação embaralhada usando a chave pública pode ser recuperada apenas usando a chave privada correspondente. Como o nome sugere, a chave pública pode ser distribuída 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 públicas, permitindo que um envie informações para o outro de forma segura.
Instalar o servidor SSH é bastante simples, basta instalar o pacote "openssh-server" usando o gerenciador de pacotes. No Ubuntu, por exemplo, você usaria: $ sudo apt-get install openssh-server
A partir daí, você pode acessar a máquina remotamente a partir de outras máquinas Linux usando o comando "ssh", seguido do login usuário (na máquina remota) e o endereço, como em:$mailto:$sshgdh@192.168.1.192 Da primeira vez que fizer a conexão, ele exibe um aviso, confirmando a identificação do servidor. Depois de fornecer a senha a conexão é efetuada e você obtém um prompt de comando da máquina remota. A partir daí, todos os comandos são executados na outra máquina. A sua passa apenas a exibir a saída de texto, funcionando como um terminal remoto: No Linux, todos os aplicativos podem ser chamados via linha de comando. Quase sempre, o comando é o próprio nome do aplicativo, como em "firefox", "konqueror", "nautilus" e assim por diante. Experimente abrir alguns programas; você verá que eles são exibidos na sua máquina local, muito embora estejam sendo executados na outra máquina. O uso de aplicativos gráficos funciona muito bem (permitindo que você use o SSH como um sistema de terminal server) via rede local e pode até mesmo ser usado via internet, embora nesse caso a velocidade de atualização seja muito baixa: Você logo perceberá que ao abrir qualquer aplicativo, ele bloqueia o terminal, impedindo que você abra outros antes de finalizá-lo. Para evitar isso, edicione um "&" no final do comando, como em:
$ firefox &
Isso faz com que ele rode em segundo plano. O terminal ainda exibirá algumas mensagens de erro e avisos relacionados ao aplicativo, mas é melhor do que ficar inteiramente bloqueado.
Para fechar a conexão com o servidor, pressione "Ctrl+D" no terminal, ou use o comando "exit". (ela é também automaticamente encerrada se você fechar o terminal). Se você quiser apenas encerrar o aplicativo atual, pressione "Ctrl+C".
O SSH possui vários mecanismos de segurança, que tornam praticamente impossível capturar os dados transmitidos durante a conexão. Isso faz com que ele seja a ferramenta de acesso remoto mais usada no mundo. Por outro lado, os sistemas empregados podem complicar um pouco as coisas em diversas situações. Vamos a alguns problemas comuns que podem ser rapidamente solucionados.
A primeira dica é que, para rodar aplicativos gráficos, você deve se logar usando diretamente o usuário desejado. Se você quer rodar algum utilitário como root, você deve logar-se diretamente como root, como em:
# ssh root@servidor
Lembre-se de que no Ubuntu/Kubuntu e distribuições derivadas deles é necessário primeiro definir uma senha para o root usando o comando "sudo passwd" antes de conseguir se logar:
$ sudo passwd
Se você se logar usando um login e depois mudar para o root (ou outro login qualquer) usando o "su", as permissões de acesso ao ambiente gráfico não são atualizadas, de forma que os aplicativos gráficos deixam de funcionar. Uma solução é instalar o pacote "sux" e passar a usar o comando no lugar do su. O "sux" atualiza as permissões do ambiente gráfico, solucionando o problema.
Algumas distribuições, como o Ubuntu e o Slackware desativam (no cliente) o uso de aplicativos gráficos por padrão. Nesses casos, você deve adicionar o parâmetro "-X" no comando de conexão, como em:
$ ssh -X usuario@servidor
Se você estiver tentando se logar no servidor como root e ele teimar em recusar a senha (que você sabe estar correta), é provável que a distribuição usada venha configurada para recurar os logins como root por padrão. Nesse caso, logue-se usando um login de usuário, use o comando "su -" (ou o sux) para se logar como root e abra o arquivo "/etc/ssh/sshd_config" (que é o principal arquivo de configuração do servidor SSH), usando um editor de texto, como em:
# mcedit /etc/ssh/sshd_config

(o editor mcedit faz parte do pacote "mc")
Dentro do arquivo, procure pela linha "PermitRootLogin no" e substitua o "no" por "yes" por:
PermitRootLogin yes
Salve o arquivo e reinicie o servidor SSH (ainda logado como root) usando o comando "/etc/init.d/ssh restart" para que a alteração entre em vigor.
Ao conectar, o SSH verifica a identificação do servidor remoto (comparando com a chave que ele grava ao efetuar a primeira conexão) e aborta a conexão caso o servidor tenha sido substituído por outra máquina. Isso evita que alguém mal intencionado consiga roubar sua senha ao substituir o servidor por outra máquina configurada para usar o mesmo endereço: O problema é que isso também acontece quando você reinstala o sistema ou troca o servidor por outra máquina. Nesse caso, é necessário apagar a chave antiga manualmente. Para isso abra o arquivo ".ssh/know_hosts" que fica dentro do seu diretório home (no cliente), usando qualquer editor de texto e apague a linha que começa com o endereço do servidor:
$ kedit ~/.ssh/know_hosts
Continuando, existem também clientes SSH para o Windows. Além de permitirem que você acesse máquinas Linux remotamente, eles ao uma boa forma de rodar aplicativos Linux em máquinas Windows, sem precisar usar o VMware ou outro software de virtualização. Sempre que você se conecta a outra máquina usando o SSH, é aberta uma nova sessão, se forma que você pode rodar aplicativos remotamente sem atrapalhar o usuário que está usando a máquina. A única recomendação é que você use dois logins separados, já que muitos aplicativos não aceitam ser abertos duas vezes.
O cliente SSH Windows mais usado é o Putty, um programa gratuito e bastante completo, que não precisa sequer ser instalado para rodar. Basta baixar o "putty.exe" no http://www.putty.nl/ e executar o programa.
Na tela principal, forneça o endereço do servidor e clique no "Open". Ele abre um terminal solicitando o login e senha e efetua a conexão: O Putty oferece várias opções de personalização e solução de problemas. Ao conectar a um PC com o Ubuntu ou outra distribuição que use UTF, por exemplo, você vai perceber que muitos caracteres ficam trocados. Para solucionar o problema, acesse a opção "Windows > Translation" e escolha a opção "UTF-8" no campo "Received data assumed to be in which character set".
Continuando, o terminal do Putty permite rodar comandos e qualquer aplicativo em modo texto sem limitações, mas ao tentar rodar algum aplicativo gráfico, você vai receber uma mensagem avisando que não é possível se conectar ao display: Isso acontece por que para ser executado, o programa precisa que um servidor X (o servidor gráfico usado no Linux e outros sistemas Unix) esteja sendo executado no cliente, o que naturalmente não é o caso do Windows.
Para solucionar o problema, precisamos instalar um servidor X. Existem diversas opções de softwares comerciais, como o Win32 (http://xwin32.dk) e o WinaXe (http://labf.com), mas uma opção muito melhor é o Xming, um software gratuito e de código aberto, disponível no:http://www.straightrunning.com/XmingNotes/
Além do "Xming" (o pacote principal) é necessário instalar o "Xming-fonts", que contém fontes de tela usadas pelo servidor X (ele não funciona sem elas). Quando aberto, o Xming fica residente ao lado do relógio, esperando que algum aplicativo precise dele: Para usá-lo em conjunto com o Putty, marque (no Putty) a opção "Connection > SSH > X11 > Enable X11 X11 forwarding" (sem colocar nada no campo "X display location"). Isso faz com que o Putty encaminhe todas as requisições gráficas para o Xming, permitindo que os aplicativos gráficos rodem normalmente, mesmo no Windows! Os aplicativos rodam normalmente, com a mesma aparência. A única diferença visível é que eles passam a usar a decoração de janela do Windows: Se você se conecta sempre nas mesmas máquinas, você pode também usar o Xming para criar ícones no desktop, que abram os aplicativos gráficos diretamente. Para isso, use o Xlaunch, que faz parte do pacote.
Na tela inicial, use a opção "Multiple windows" (que faz o programa rodar em sua própria janela, como se fosse um aplicativo nativo) e na segunda marque a opção "Start a program" Na terceira janela (a mais importante) vai o comando para abrir o programa desejado, o endereço do servidor, o login e a senha. Marque a opção "Using Putty (plink.exe)", que usar o próprio cliente SSH incluído no Xming. Na tela final, use o botão "Save configuration" para criar o atalho (existe uma opção para salvar a senha, mas ela não é muito recomendável, pois a salva em texto puro dentro do arquivo): Além de criar atalhos para um ou dois programas específicos, você pode criar um para abrir um terminal ("gnome-terminal", "konsole", "xterm" ou outro), que pode então ser usado para abrir outros programas desejados. É uma boa forma de impressionar os amigos, já que a maioria não vai saber explicar como é que você está conseguindo rodar aplicativos Linux dentro do Windows, sem usar o VMware:
Como se não bastasse, o SSH permite também transferir arquivos, através do módulo SFTP, que vem ativo por padrão. Ele utiliza o mesmo túnel encriptado usado para rodar os aplicativos remotamente, garantindo a segurança da transmissão.
O SFTP utiliza a mesma porta do SSH, a porta 22, de forma que você não precisa se preocupar em deixar nenhuma outra porta aberta no firewall. Desde que o SSH esteja ativo, o SFTP também estará.
Nos clientes Linux, você pode acessar os arquivos do servidor usando o Konqueror (no KDE), ou o Nautilus (no Gnome). Se nenhum dos dois estiver disponível, é possível usar também o GFTP, que pode ser instalado usando o gerenciador de pacotes.
No Konqueror, digite "fish://", seguido pelo login e o endereço do servidor (separados por uma arroba) na barra de endereços, como em "fish://gdh@192.168.1.22". Ele exibe uma janela gráfica pedindo a confirmação da identidade do servidor (apenas na primeira conexão) e em seguida outra solicitando a senha: Uma dica é que você pode usar o recurso do Konqueror de separar a janela em duas (Janela > Separar a visão em Topo/Base) para facilitar as transferências de arquivos. Você pode ter então uma metade exibindo os arquivos do servidor remoto e outra exibindo os arquivos locais, podendo assim arrastar os arquivos de uma para a outra.
No Nautilus, clique em "Arquivo > Conectar ao servidor". Na janela seguinte, escolha "SSH" na opção "Tipo de serviço" e forneça o endereço do servidor e o login que será usado, no campo "Nome do Usuário". O campo com a pasta permite especificar qual pasta será acessada por padrão ao efetuar a conexão, mas ela é opcional. O campo "Porta" é usado apenas caso você tenha configurado o servidor SSH para escutar uma porta diferente da 22: Isso cria um ícone de acesso, que aparece tanto no desktop quanto na barra "Locais" do Nautilus. Para finalmente efetuar o acesso, você clica sobre o ícone e fornece a senha. Para encerrar o acesso, clica sobre ele com o botão direito e usa a opção "Desmontar": Para acessar usando o GFTP, você deve mudar a opção de protocolo (o campo do lado direito da tela) de "FTP" para "SSH2". Com isso ele automaticamente acessa o servidor na porta 22, usando o protocolo SFTP. Assim como no caso do Nautilus, só é necessário especificar a porta caso o servidor tenha sido configurado para usar uma porta diferente da 22: No Windows você pode utilizar 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: É possível também acessar os arquivos via linha de comando usando o comando "sftp usuario@servidor" (no Linux) ou o PSFTP (disponível na mesma página do Putty) no Windows. Em ambos os casos, você usa o comando "cd" para alternar entre os diretórios e os comandos "put" e "get" para transferir arquivos.
Proximo Tutorial vou mostrar Como vcs podem Configurar o Ubuntu Server como um Keche full com o  thunder cache.
Então até a Proxima Galerra e Qualquer Duvidas: deixem comentarios ai ou mandem e-mail: winfox@winfoxtw.com.br

4 comentários:

  1. Parabéns!Parabéns!Parabéns!
    Você, como poucos, explicou muito, mas muito mesmo, usando poucas e simples palavras. Texto claro, objetivo. Pode se candidatar a escritor, professor, pastor e outros ORs, kkkk!

    ResponderExcluir
  2. Muito obrigado parceiro ajudou bastante!!!, parabéns

    ResponderExcluir
  3. Parabéns pela tua iniciativa. Sou grato pela luz.

    ResponderExcluir