Apostila Linux Avançada

Prévia do material em texto

A P O S T I L A
D E
G N U / L I N U X
1. KERNEL
Kernel de um sistema operacional é entendido como o núcleo deste ou, numa 
tradução literal, cerne. Ele representa a camada mais baixa de interface com o 
Hardware, sendo responsável por gerenciar os recursos do sistema computacional 
como um todo. É no kernel que estão definidas funções para operação com 
periféricos (mouse, disco, impressora, interface serial/interface paralela), 
gerenciamento de memória, entre outros. Resumidamente, o kernel é um conjunto 
de programas que fornece para os programas de usuário (aplicativos) uma interface 
para utilizar os recursos do sistema.
Quanto à sua arquitetura, o kernel pode ser monolítico - em um único bloco, com 
todas as funcionalidades carregadas na memória - ou modular (micro-kernel) - com 
os módulos específicos para cada tarefa carregados opcionalmente, dinamicamente.
O kernel é a parte mais importante do sistema operacional, pois, sem ele, a cada 
programa novo que se criasse seria necessário que o programador se preocupasse 
em escrever as funções de entrada/saída, de impressão, entre outras, em baixo 
nível, causando uma duplicação de trabalho e uma perda enorme de tempo. Como o 
kernel já fornece a interface para que os programas possam acessar os recursos do 
sistema de um nível mais alto e de forma transparente, fica resolvido o problema da 
duplicação do trabalho.
Quando há periféricos ou elementos de um sistema computacional que o kernel não 
cobre, então se faz necessário escrever a interface para eles, os chamados device 
drivers. Geralmente, os kernels oferecem uma função para se executar chamadas 
de sistema, como por exemplo a ioctl(), função essa que podemos denominar de I/O 
Control do Linux. Valendo-se dessa função, podem-se escrever rotinas para 
qualquer dispositivo.
1.1 Kernel monolítico.
Kernel monolítico ou mono-bloco é um kernel que implementa um interface de alto 
nível para possibilitar chamadas de sistema específicas para gestão de processos, 
concorrência e gestão de memória por parte de módulos dedicados que são 
1
A P O S T I L A
D E
G N U / L I N U X
executados com privilégios especiais.
Alguns exemplos deste tipo de kernel:
• BSD
• Linux
1.2 Micro-Kernel.
Micro-kernel é um termo usado para caracterizar o sistema cujas funcionalidades do 
sistema saíram do kernel e foram para servidores, que se comunicam com um 
núcleo mínimo, usando o mínimo possível o "espaço do sistema" (nesse local o 
programa tem acesso a todas as instruções e a todo o hardware) e deixando o 
máximo de recursos rodando no "espaço do usuário" (no espaço do usuário, o 
software sofre algumas restrições, não podendo acessar alguns hardwares, nem tem 
acesso a todas as instruções).
Alguns exemplos deste tipo de kernel:
• Hurd 
• Minix 
• Microsoft Windows NT 
2
A P O S T I L A
D E
G N U / L I N U X
1.3 Recompilando o Kernel.
A recompilação do kernel tem de ser extremamente observada. É nela que você 
poderá colocar suporte a muitos tipos de hardwares, habilitar recursos do kernel 
(como firewall e compartilhamento NAT), entre outras coisas. Muitas distribuições 
incluem kernels já compilados e prontos para usar, mas é sempre recomendado que 
você compile o seu kernel para otimizá-lo conforme suas necessidades.
Alguns pacotes precisam ser instalados antes da recompilação do kernel, entre eles, 
os pricipais são o gcc-4.0, initrd-tools, automake1.9, make e libncurses5-dev.
Pacotes de descompactação também serão necessários, portanto devemos instalar 
os pacotes tar, bzip2 e gzip.
Descompactando o kernel
Em primeiro lugar, vamos baixar uma imagem e descompactá-la em algum diretório, 
para depois começarmos a configurar a compilação. Os códigos-fonte do kernel em 
suas várias versões podem ser todos encontrados através do seguinte endereço:
 http://www.kernel.org – Página oficial do Kernel
 ftp://ftp.kernel.org — FTP oficial do Kernel
 http://ftp.kernel.org — Acesso HTTP ao FTP oficial do Kernel
 ftp://ftp.br.kernel.org — Mirror Brasileiro do FTP do kernel
Para facilitar, vamos um browser em modo texto para baixar a última versão do 
kernel, para isso deveremos instalar o links através do apt-get com o seguinte 
comando:
# apt-get install links
Para acessarmos a página do kernel devemos digitar o seguinte comando no shell:
# links www.kernel.org
Vamos baixar a última versão disponível do kernel, utilizando a seta de 
direcionamento para baixo até chegarmos a letra F (Full), em seguida precione a 
letra D (download) e em seguida pressione a tecla enter para iniciar o download.
Terminado o download, utilizaremos o comando mv para mover o pacote do kernel 
para o diretório /usr/src.
# mv linux-v.x.y.z.tar.bz2 /usr/src
Agora, portanto é hora de descompactarmos o código fonte do kernel, para isso 
3
A P O S T I L A
D E
G N U / L I N U X
utilizaremos a seguinte linhas de comando:
# cd /usr/src
# tar -xvjf linux-v.x.y.z.tar.bz2
Para facilitar, criaremos um link simbólico do diretório nos quais os fontes do kernel 
foram extraidos.
# ln -s linux-v.x.y.z linux
No proximo passo, iniciaremos a configuração para posteriormente compilarmos o 
kernel.
# cd linux
# make menuconfig
É extremamente necessário que você tenha todo o conhecimento sobre o hardware 
utilizado no computador, e serviços para os quais ele deverá atender.
Para verificarmos uma listagem simplificada de hardware, utilizaremos o segundo 
terminal disponível, apertando as teclas Alt+F2.
Em seguida, digitaremos o seguinte comando:
# lspci
4
A P O S T I L A
D E
G N U / L I N U X
Desta forma saberemos quais são os principais hardwares instalados no computador 
para que possamos passar informações corretas ao kernel.
Sabendo qual é o tipo de hardware existente no computador, retornaremos à janela 
de configuração do kernel pressionando as teclas Alt+F1.
Dentro das configurações do kernel Linux, podemos setar as opções como build in 
(compilado diretamente dentro de uma única estrutura do kernel, sendo carregado 
sempre que o computador for iniciado e é representado por um *) ou podemos ainda 
setar as opções como modules (modulos que podem ou não ser carregados pelo 
kernel em sua inicialização e é representado pela letra M).
Após todas as modificações necessárias, iremos salvar o arquivo de configuração 
selecionando a opção “Save Configuration to an Alternate File”
Agora iremos salvar as configurações do kernel com o nome de config-meu-kernel 
(pode ser qualquer outro nome desde que se recorde posteriormente).
5
A P O S T I L A
D E
G N U / L I N U X
Agora é só sair selecionando a opção Exit ele irá questionar se deseja salvar, 
selecione Yes.
Com o kernel configurado, iniciaremos a compilação com o seguinte comando:
# make bzImage
Se todas as configurações do kernel estiverem corretas, o kernel já estará compilado 
e será salvo dentro do diretório /usr/src/linux/arch/i386/boot/ , caso contrário, 
deveremos reconfigurá-lo identificando na mensagem de erro qual o causador do 
problema e rodar novamente o comando acima descrito.
O próximo passo é instalar os módulos. Para isso utilizaremos os seguintes 
comandos:
# make modules
# make modules_install
Vamos agora copiar a imagem do kernel compilado, do nosso arquivo de 
configurações e um arquivinho chamado System.map para o diretório /boot nota-se 
que o nome do kernel geralmente iniciá-se por vmlinuz, portanto ao copiarmos o 
arquivo bzImage, já estaremos renomeando-o com esse prefixo mais sua versão 
tudo isso com os seguintes comandos:
6
A P O S T I L A
D E
G N U / L I N U X
# cp /usr/src/linux/arch/i386/boot/bzImage/boot/vmlinuz-v.x.y.z
# cp /usr/src/linux/System.map /boot
# cp /usr/src/linux/config-meu-kernel /boot
Agora é necesário criarmos uma imagem initrd, que é uma imagem relativa aos 
procedimentos de inicialização do sistema, para isso usaremos o seguinte comando:
# mkinitrd /lib/modules/v.x.y.z/ -o /boot/initrd-v.x.y.z.img
Para organizar a estrutura de kernels, uma vez que pode-se ter mais de um no 
sistema operacional GNU/Linux, vamos criar links simbólicos no diretório raiz com os 
seguintes comandos:
# ln -s /boot/vmlinuz-v.x.y.z /
# ln -s /boot/initrd.v.x.y.z.img /
Agora é só adicionar as linhas no /etc/lilo.conf e redar o comando lilo ou adicionar 
em menu.lst dentro do diretório /boot/grub/ conforme já aprendido acima.
CUIDADO!!!
Lembre-se de sempre adicionar uma nova entrada em seu arquivo de configuração 
do kernel, não é seguro substituí-las, pois, o novo kernel pode não funcionar após a 
próxima reinicialização.
7
A P O S T I L A
D E
G N U / L I N U X
2. SERVIDOR DHCP
O DHCP (Dynamic Host Control Protocol) é um protocolo utilizado para 
endereçamento dinâmico de hosts. Através do DHCP, é possível endereçar uma 
grande quantidade de hosts de uma rede, sem perder um grande tempo 
configurando estações de trabalho.
Existe um serviço no GNU/LINUX chamado dhcpd que pode ser configurado para 
fornecer endereços IP's automaticamente para os clientes da rede. Com isso, o 
administrador da rede ganha tempo, tem uma configuração mais confiável e muito 
mais estável em todas as suas estações. Além disso, é possível ter um controle dos 
endereços utilizados pelos hosts da rede e fornecer algumas configurações 
adicionais, tais como, endereço de gateway, servidor de DNS primário, servidor de 
DNS secundário, entre outros.
2.1 Instalando o servidor e cliente dhcp.
Para instalar o servidor e o cliente de dhcp, devemos usar o seguinte comando:
# apt-get install dhcp3-server dhcp3-common dhcp-client
Instalado o servidor, daremos início à sua configuração, seu arquivo encontra-se 
dentro do diretório /etc/dhcp3/dhcpd.conf
As linhas que contiverem # na frente, não serão lidas pelo servidor DHCP, pois 
estarão comentadas.
# vi /etc/dhcp3/dhcpd.conf
ddns-update-style none;
Esta opção especifica se o servidor DHCP deverá tentar atualizar o DNS quando 
um arrendamento é aceito ou devolvido. Na implementação da ISC, esta opção é 
obrigatória.
option domain-name "marcioleonardi.com.br";
8
A P O S T I L A
D E
G N U / L I N U X
Esta opção especifica o domínio que será fornecido aos clientes como o principal 
domínio de busca.
option domain-name-servers 200.167.216.14,200.167.216.15;
Esta opção especifica uma lista separada por vírgulas de servidores DNS que o 
cliente deve utilizar.
default-lease-time 600;
Um cliente pode requerer um período de tempo específico válido para um 
arrendamento. Senão o servidor deverá fazer um arrendamento com este prazo de 
expiração (em segundos). 
max-lease-time 7200;
Se você tiver mais endereços IP do que máquinas os endereços IP das estações 
raramente vai precisar mudar. Mas, no caso de uma rede congestionada, o " max-
lease-time" determina o tempo máximo que uma estação pode usar um 
determinado endereço IP. Isso foi planejado para ambientes onde haja escassez de 
endereços IP, em condições normais estas duas opções não são muito 
importantes. 
authoritative;
Em uma rede com 2 servidores DHCP, esta opção o torna padrão da rede local.
subnet 192.168.1.0 netmask 255.255.255.0 {
 range 192.168.1.101 192.168.1.254;
 option routers 192.168.1.1;
}
A opção "range" determina a faixa de endereços IP que será usada pelo servidor. 
Se você utiliza a faixa de endereços 192.168.1.0 até 192.168.1.254 por exemplo, 
pode reservar os endereços de 192.168.1.1 a 192.168.1.100 para estações 
configuradas com IP fixo e usar os demais para o DHCP.
A opção routers declara o gateway padrão que será fornecido aos clientes.
host Marcio {
 hardware ethernet 00:0C:6E:8E:F7:9A;
 fixed-address 192.168.1.5;
9
A P O S T I L A
D E
G N U / L I N U X
}
O endereço MAC de um sistema (de forma que o servidor DHCP possa reconhecê-
lo quando dele receber uma solicitação).
Especifica que o sistema sempre deve receber o mesmo endereço IP. Note que um 
hostname funciona aqui, desde que o servidor DHCP seja capaz de resolver o 
nome via DNS antes de responder à solicitação com as informações do 
arrendamento.
Desta forma estará finalizada a configuração do seu servidor DHCP devendo iniciá-
lo através do seguintes comandos:
# /etc/init.d/dhcp3-server stop
# /etc/init.d/dhcp3-server start
10
A P O S T I L A
D E
G N U / L I N U X
3. SERVIDOR FTP
FTP significa File Transfer Protocol (Protocolo de Transferência de Arquivos), e é 
uma forma bastante rápida e versátil de transferir arquivos, sendo uma das mais 
usadas na internet.
Pode referir-se tanto ao protocolo quanto ao programa que implementa este 
protocolo (neste caso, tradicionalmente aparece em letras minúsculas, por influência 
do programa de transferência de arquivos do Unix).
A transferência de dados em redes de computadores envolve normalmente 
transferência de arquivos e acesso a sistemas de arquivos remotos (com a mesma 
interface usada nos arquivos locais). O FTP (RFC 959) é baseado no TCP, mas é 
anterior à pilha de protocolos TCP/IP, sendo posteriormente adaptado para o TCP/IP. 
É o standard da pilha TCP/IP para transferir arquivos, é um protocolo genérico 
independente de hardware e do sistema operacional e transfere arquivos por livre 
arbítrio, tendo em conta restrições de acesso e propriedades dos arquivos.
Existem diversos servidores FTP disponível para GNU/Linux, vamos utilizar o 
ProFTPd como exemplo para nossa experiência.
3.1 Instalando o ProFTPd.
Como já vimos antes, vamos instalar o servidor através do comando apt, com os 
seguintes parâmetros:
# apt-get install proftpd proftpd-common
3.2 Configurando o ProFTPd.
Como todo daemon de um sistema GNU/Linux e Unix, o ProFTPd é configurado 
através de um arquivo texto, o /etc/proftpd.conf. Com um simples editor de texto é 
possível efetuar sua configuração. É interessante observar que o ProFTPd apenas lê 
seu arquivo de configuração ao ser iniciado. Portanto após cada modificação 
deveremos reiniciá-lo.
A sintaxe do arquivo /etc/proftpd.conf é simples. O ProFTPd usa o conceito de 
contextos em sua configuração e nestes contextos temos as chamadas diretivas. 
Contexto é uma configuração global de um certo comportamento do ProFTPd 
11
A P O S T I L A
D E
G N U / L I N U X
enquanto as diretivas são as sub-opções que configuram os contextos. 
Contextos do ProFTPd.
Basicamente temos dois contextos principais:
Contexto Principal: Contém as configurações default que serão utilizados inclusive 
por outros contextos.
Contexto <Directory DIR >: Determina o comportamento do ProFTPd quando 
acessando e/ou servindo o diretório DIR.
Abaixo temos um exemplo de configuração do ProFTPd (perceba que é a 
configuração default de nossa versão customizada).
Exemplo 1. exemplo do configuração do ProFTPd
#Configuração do ProFTPd
ServerName "FTP-TESTE"
ServerType standalone
DefaultServer on
ServerAdmin root@localhost
#Para efetuar download aos pedaços
AllowRetrieveRestart on
#porta 21 padrão
port 21
#Umask 022 é um bom padrão pra prevenir que novos diretórios e 
arquivos
#sejam graváveis pelo grupo de usuários
Umask 022
#Quantidade máxima de instâncias
MaxInstances 10
#Usuário e grupo para o servidor no caso de especificação 
12A P O S T I L A
D E
G N U / L I N U X
especifica
#User nobody
#Group nobody
#Autenticação de usuário...utilizando o usuário do própio server 
GNU/Linux
AuthUserFile /etc/passwd
#login como root
RootLogin on
#Faz com que o usuário apenas acesse seu diretório $HOME
DefaultRoot ~
<Directory /*>
Todas as devias alterações realizadas vamos reiniciar o processo com o seguinte 
comando:
# /etc/init.d/proftpd stop
# /etc/init.d/proftpd start
13
A P O S T I L A
D E
G N U / L I N U X
Algumas diretivas do contexto principal:
14
A P O S T I L A
D E
G N U / L I N U X
Algumas diretivas do contexto <Directory>
15
A P O S T I L A
D E
G N U / L I N U X
4. SERVIDOR OPENSSH
O Secure Shell ou SSH é, simultaneamente, um programa de computador e um 
protocolo de rede que permite a conexão com outro computador na rede, de forma a 
executar comandos de uma unidade remota. Possui as mesmas funcionalidades do 
TELNET, com a vantagem da conexão entre o cliente e o servidor ser criptografada. 
As redes de computadores são uma mídia inerentemente insegura. A menos que 
você tem certeza que seus pacotes nunca irão passar por um roteador ou 
computador que você não controle direto sobre, seus dados não estão seguros. Eles 
podem ser visualizados por sysadmins pouco confiáveis ou por um script kiddie, ele 
pode ser alterado em trânsito, ou pode ser interceptado e trocado por dados 
completamente diferentes.
4.1 Criptografia e Assinaturas Digitais.
Como mensionado anteriormente, você não pode simplesmente confiar em qualquer 
dado que passe pela Internet sem algum método para garantir que o dado que você 
envia é o mesmo dado que é recebido do outro lado. Isto parece paranóico, e na 
maioria dos casos é, mas é sempre melhor estar seguro que ter problemas. É muito 
fácil para qualquer um falsificar os seus dados durante o trânsito. E se você tem 
dados que são sensíveis ou privados, certamente você não vai querer que J. 
Random Hacker ou H. Bored Sysadmin leia o mesmo. É aqui onde a criptografia e a 
assinatura digital entram.
Vejamos um exemplo concreto de um problema típico de segurança. Suponha que o 
servidor A deseje envia uma mensagem ao servidor B. Se a mensagem for enviada 
descriptografada e passa pelo roteador C, qualquer informação enviada é visível a 
root@C. Se root@C é hostil, ele pode resolver ler o que o servidor A está tentando 
enviar para o servidor B, e, em vez de repassar a mensagem, enviar uma 
mensagem falsa para B, e fazer a mesma coisa no retorno de B para A. Este é o 
ataque conhecido como "man-in-the-midle" ou "intermediário".
16
A P O S T I L A
D E
G N U / L I N U X
Dados Sensíveis
Tipicamente os pacotes enviados pela Internet viajam por vários roteadores antes de 
chegar a seu destino. Cada um destes roteadores é um perigo potencial e possui 
completo acesso a seus dados. Esta é, claramente, uma situação inaceitável para 
muitos dados importantes ou sensíveis. Infelizmente as pessoas constantemente 
estão enviando segredos da empresa, informações pessoais, senhas, números de 
cartão de crédito, e outros dados privados não criptografados pela internet. Ou elas 
não percebem o perigo disto ou simplesmente não acreditam que valha o esforço a 
própria proteção.
Autenticação
Outra área em que a técnica de criptografia é usada é na área de autenticação - 
como eu fico sabendo que você é quem você diz ser? Um nome de login e senha 
podem ter sido seguros há 20 anos atrás, mas eles são facilmente roubados ou 
violados. E um esquema de login e senha pode fornecer um serviço básico de 
autenticação, mas uma vez autenticado, eles não garantem que os dados recebidos 
sejam exatamente os mesmos que foram enviados. Criptografia e assinaturas 
digitais são extremamente importantes para resolver estes problemas 
(particularmente sistemas de chave pública).
Criptografia de Chave Privada vs. Pública
Tradicionalmente a criptografia têm se baseado em um segredo compartilhado, 
conhecido como chave. Esta chave é usada em uma fórmula matemática para 
embaralhar a informação em questão de forma que ela não possa ser 
desembaralhada facilmente sem o conhecimento da chave secreta. Enquanto esta 
técnica pode ser bem segura quando estiver em uso um bom algoritmo e uma chave 
de tamanho razoável, ela introduz o problema da troca de chaves. Como você pode 
se comunicar com um host remoto na Internet quando você não tem um canal 
seguro de comunicação que você possa utilizar para transferir a chave de 
criptografia em primeiro lugar? Este problema tem sido resolvido tipicamente pela 
transferência das chaves pessoalmente.
A presunção que a criptografia requer o compartilhamento do conhecimento de uma 
chave está tão entranhado que ele geralmente não é reconhecido. Simplesmente é 
assumido pela maioria que este é um defeito das técnicas de criptografia. 
Entretanto, tudo mudou em 1976 quando Martin Hellman, Whitfield Diffie, e Ralph 
Merkle apresentaram a idéia da criptografia de chave pública na Stanford University.
A criptografia de chave pública aborda o problema de um ângulo completamente 
diferente. Aqui temos 2 chaves - uma chave privada, que é protegida 
cuidadosamente, e uma chave pública, que pode ser passada a quem a quiser. A 
chave pública pode ser derivada da chave privada, mas não vice-versa. Os 
17
A P O S T I L A
D E
G N U / L I N U X
algoritmos de chave pública possuem a propriedade que os dados criptografados 
pela chave pública podem ser somente descriptografados pela chave privada 
correspondente.
Com esta descoberta, o problema da troca de chaves está praticamente resolvido. 
Não há mais necessidade de uma mídia segura para a transferência inicial de 
chaves, mas você pode simplesmente criptografar os dados com a chave pública do 
recipiente e ter certeza que os dados só podem ser recuperados com a chave 
privada dele, a qual nunca precisa sair do controle dele. Isto também resolve o 
problema mencionado acima da autenticação - se você quer ter certeza que alguém 
é quemdiz ser, simplesmente criptografe uma pequena quantia de dados (conhecida 
como "desafio") usando sua chave pública, e envie a esta pessoa. Esta pessoa 
então descriptografa a mesma com sua chave privada e envia de volta 
(possivelmente criptografada com tua chave pública). Se os dados que você receber 
são idênticos aos dados originalmente enviados, você sabe que ele é quem diz ser.
Então por quê a criptografia de chave privada ainda é utilizada? A razão tem a ver 
com eficiência. Os métodos atuais de criptografia com chave pública são muito mais 
lentos que os métodos de chave privada, tornando, desta forma, impraticável a 
criptografia de enormes quantias de dados. Frequentemente, (como com o SSH), 
um método de chave pública pode ser utilizado para autenticação e para a troca de 
uma chave privada. Se tudo der certo com estes dois passos, a criptografia de chave 
privada pode ser usada.
Funções de Hash
Uma função de Hash é simplesmente uma função que pega uma enorme quantia de 
dados e encolhe a mesma para um tamanho bem menor. É uma função de uma via 
(ou seja, a informação original não pode ser determinada a partir do hash 
resultante). Funções criptográficas de hash tem a propriedade adicional que uma 
pequena alteração nos dados originais resulta em uma grande alteração no hash 
resultante, o que torna extremamente difícil alterar os dados e manter o mesmo hash 
resultante.
Assinaturas Digitais
Assinaturas digitais fazem uso das funções de hash criptográficas para mostrar que 
o que o recipiente vê é, defato, a informação que foi originalmente enviada. 
Algoritmos de assinatura digital típicos são baseados na criptografia de chave 
pública, e uma visão simplificada de como funcionam é mostrada no seguinte 
exemplo:
A pessoa A compõe um email para a pessoa B. Quando o email está pronto para ser 
enviado, ele é passado por um algoritmo criptográfico de hash e o hash resultante é 
criptografado com a chave privada de A e anexado ao email. Quando a pessoa B 
recebe o email, ela descriptografa a assinatura com a chave pública de A e passa o 
18
A P O S T I L A
D E
G N U / L I N U X
email pelo mesmo algoritmo de hash. Se o hash resultante é idêntico ao hash 
descriptografado, a pessoa B pode confiar que o email não foi adulterado durante o 
transporte. Mesmo pequenas alterações, como o acréscimo de pontuações ou 
espaços irá resultar em um hash completamente diferente.
Assinaturas digitais são uma exigência legal em alguns estados por que são 
(praticamente) impossíveis de serem forjadas - certamente são muito mais difíceis 
de forjar que uma assinatura física. Uma aplicação popular para a criação e 
verificação de assinaturas digitais (bem como criptografar e descriptografar) é o 
PGP, ou sua alternativa livre, o GnuPG.
4.2 Instalação do OpenSSH
Para instalarmos o OpenSSH, serão necessários 3 (três) pacotes, que deverão ser 
instalados via apt-get com o seguinte comando:
# apt-get install openssh-server openssh-client ssh
4.3 OpenSSH Básico
O OpenSSH é uma implementação livre dos protocolos SSH, versão 1 e 2. O nome 
secure shell é um pouco equivocado, uma vez que o mesmo não é um shell da 
mesma forma que o bash ou do tcsh são shell, mas é mais do tipo do rsh. Ele é 
usado quando é preciso fazer um acesso remoto seguro a uma máquina Unix, mas 
devido à prevalência de script kiddies que adorariam conseguir sua senha e ober 
acesso livre a teus servidores, é uma boa idéia usar o mesmo sempre que você 
precisar fazer algum acesso remoto.
O uso mais básico do ssh, e a forma que ele é usado pela maioria das pessoas, é 
como substituto do telnet. O telnet transmite toda comunicação, incluindo o login e 
senha, em texto plano, e esta informação pode facilmente ser interceptadapor 
qualquer um que tenha acesso físico a qualquer rede ou roteador em que os seus 
pacotes passarem. Qualquer coisa transmitida pela Internet em texto plano é jogo 
fácil para qualquer um, por isto você tem que ser cuidadoso. Usar o ssh ao invés do 
telnet torna muito mais difícil sua informação ser capturada.
O uso básico do ssh é simples. Vamos por exemplo conectar via SSH no nosse 
endereço de loop-back 127.0.0.1, e com nosso usuário comum desta forma você 
pode usar o seguinte comando:
$ ssh acc@127.0.0.1
Dependendo de sua versão do ssh, você pode também ver uma mensagem 
mostrando a fingerprint da chave do host remoto. Esta está ligada a um hash da 
chave, e se você estiver sendo extremamente cuidadoso você vai trocar as 
fingerprints com o administrador do host remoto através de uma linha segura (tipo 
um telefone ou pessoalmente) antes de fazer a conexão, e então verificar se as 
19
A P O S T I L A
D E
G N U / L I N U X
fingerprints são idênticas. Isto é para proteger-se de um ataque "man-in-the-middle" 
que eu discuti acima, onde alguém fica entre você e o servidor, trocando as chaves e 
criptografando e descriptografando suas comunicações de uma forma que é 
transparente tanto para você quanto para o servidor, mas permitindo-o ver (e alterar) 
toda a comunicação.
Uma vez que o ssh tenha feito a conexão, ele irá pedir pela sua senha. Esta é a 
senha associada à conta de usuário na máquina remota que é idêntica ao username 
que você forneceu ao ssh (se você não fornecer um username, o ssh assume que 
você quer usar o username no qual você está logado atualmente na sua máquina). 
Quando você informar a senha, o ssh criptografa a mesma e a envia para o servidor 
remoto. Se a senha for idêntica à senha associada à conta remota, o ssh cria um 
login shell e loga você na máquina remota. A partir deste ponto, você pode usar a 
máquina como se estivesse logado no console.
Existem duas versões diferentes do protocolo ssh - ssh1 e ssh2 (ambos são 
suportados pelo OpenSSH). Várias vulnerabilidades foram descobertas no ssh1, e a 
recomendação em geral é que se use o ssh2.
4.4 SSH Port Forwarding
O telnet e outros mecanismos de login estão longe de serem os únicos protocolos de 
rede que tem o mau hábito de transmitir informações descriptografadas. Muitos 
protocolos comuns, como HTTP, POP3, ou IMAP, transmitem as informações em 
texto plano, possivelmente incluindo logins e senhas. Enquanto cada um destes 
protocolos tem uma versão protegida pelo SSL, as versões seguras não são tão 
comuns quanto as versões não protegidas. Além disto, a instalação de versões 
protegidas pelo SSL requer o uso de privilégios de superusuário, e se, por exemplo, 
você lê seu email via IMAP de um servidor remoto para o qual você não tem controle 
direto, você não pode instalar o IMAP-S.
O SSH vem para o resgate aqui. Desde que você tenha acesso shell ao servidor que 
você deseja se conectar, o SSH pode criar um tunel criptografado para você usar 
como canal para suas conexões de rede. Ele faz isto criando uma conexão segura 
ao servidor, abrindo uma porta na sua máquina local, e canalizando tudo que recebe 
na porta local para uma porta específica no servidor remoto.
Vamos usar o IMAP com exemplo, já que é ele que eu uso para verificar meu email. 
Digamos que você queira recuperar seus emails de um servidor de nome "vacuum". 
vacuum está rodando um servidor IMAP, mas não um protegido pelo SSL, e você 
prefere não transmitir seu username e senha descriptografados. Você pode chamar 
o ssh com o seguinte comando:
$ ssh -L2001:vacuum:143 bob@vacuum
20
A P O S T I L A
D E
G N U / L I N U X
Este comando diz ao ssh para abrir a porta local 2001 e repassar a conexão para a 
porta 143 em vacuum, e logar em vacuum como bob para isto. Uma vez que você 
consiga fazer o login com sucesso no servidor remoto, você tem um tunel ssh para 
brincar. Para checar seu email agora, simplesmente informe seu cliente IMAP para 
ler seu email a partir de localhost, porta 2001. O ssh irá fazer uma conexão 
transparente para o servidor remoto.
4.5 Autenticação de chaves.
Enquanto usar o ssh com uma senha é muito mais seguro que o telnet ou rsh, ainda 
não o é sem algumas armadilhas. Ao mesmo tempo que sua senha é criptografada e 
mantida segura de outros olhos durante o trânsito pela rede, uma vez que ela 
chegue no servidor remoto ela é descriptografada novamente para texto plano antes 
da autenticação. Se o servidor remoto foi comprometido, um atacante pode substituir 
o sshd por uma versão corrompida que funciona como um cavalo-de-tróia, coletando 
senhas. Um método muito mais seguro de autenticação é a autenticação baseada 
em chaves.
A autenticação de chaves SSH é baseada nos princípios da criptografia de chave 
pública. Você tem uma chave privada que você mantém protegida e que é 
posteriormente criptografada com uma senha de acesso, e você tem uma chave 
pública que é mantida em cada servidor que você deseja acessar. Quando você 
desbloqueia sua chave privada e tenta conectar a um servidor para o qual você 
tenha dado a sua chave pública, sua chave é usada para autenticação em vez de 
sua senha. Isto significa que suas senhas nunca são enviadas à máquina remota, 
removendo desta forma toda a possibilidade de ataques de roubo de senha.
Aqui temos uma visão básica de como este processo funciona. Quando você 
conecta-se a um servidor remoto, o servidor checa para ver se suachave pública 
está no arquivo authorized_keys da sua conta remota. Se ele está, então o servidor 
criptografa algum dado aleatório com sua chave pública e o envia a você. Você 
descriptografa estes dados, criptografa o mesmo com a chave pública do servidor 
remoto, e manda-os de volta. Se o servidor descriptografar e ver que é idêntico ao 
que ele enviou originalmente a você, então ele sabe que você é quem você diz ser, e 
deixa você entrar sem precisar de senha.
Para criar um par de chaves ssh (um conjunto de chaves, uma pública, e uma 
privada), tudo que você precisa fazer é executar o seguinte comando:
$ ssh-keygen -t rsa
Este comando vai pedir por uma senha para criptografar a chave primária e vai 
salvar a mesma por padrão em ~/.ssh/identity. Mantenha esta chave 
cuidadosamente guardada! Se alguém conseguir pegar a chave e a senha que você 
usou para criptografar a mesma, este alguém pode fazer logon como se fosse você 
21
A P O S T I L A
D E
G N U / L I N U X
em todos os servidores que estiverem configurados para aceitar suas chaves! 
Depois que o comando é enviado:
Generating public/private rsa key pair.
Enter file in which to save the key (/home/acc/.ssh/identity): 
Created directory '/home/acc/.ssh'.
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/acc/.ssh/identity.
Your public key has been saved in /home/acc/.ssh/identity.pub.
The key fingerprint is:
e8:96:e0:80:06:b5:e5:e4:22:30:3b:76:47:93:95:73 acc@debian-
server
Isto é tudo que você precisa fazer! Uma vez que seu keypar tenha sido gerado, você 
pode pegar o conteúdo de identity.pub e acrescentar ao seu ~/.ssh/authorized_keys 
no servidor remoto. Uma vez que ele tenha sido acrescentado, tente conectar-se ao 
servidor remoto novamente. Quando você faz a conexão, em vez de pedir sua 
senha, ele irá perguntar pela senha que você usou para proteger sua chave privada:
$ ssh acc@debian-server
Enter passphrase for RSA key 'acc@debian-server':
Quando você informar a senha para desbloquear sua chave, o ssh usará então sua 
chave para fazer sua autenticação com o servidor remoto - sua senha nunca é 
transmitida, e nenhuma informaçõ é transmitida pela linha que possa ser mais tarde 
usada por um atacante para obter acesso a sua conta. Desde que você mantenha 
sua chave privada em segurança, sua conta está segura.
A autenticação de chaves tem outros benefícios, como a possibilidade de várias 
pessoas utilizarem a conta root sem conhecer a senha de root. Simplesmente 
acrescente as chaves públicas de cada usuário a ~/.ssh/authorized_keys, e elas 
poderão fazer o login como aquele usuário.
ssh-agent
A autenticação baseada em chaves também traz outras possibilidades interessantes. 
Por exemplo, se você está certo que ninguém que não seja de confiança irá usar 
sua sessão de login atual, você pode usar um programa chamado ssh-agent para 
manter uma cópia desbloqueada de sua chave privada na memória, de forma que 
você não precise escrever sua senha toda vez que faz um ssh para algum lugar. É 
consideravelmente mais seguro que simplesmente usar uma chave privada sem 
22
A P O S T I L A
D E
G N U / L I N U X
senha pois, mesmo quando sua chave está desbloqueada, o ssh-agent não irá dar a 
chave privada para você - ele somente assina ou descriptografa dados com ela 
(como no caso do desafio do servidor). Além disso, outras pessoas que estejam 
logadas em seu servidor (fora o root, é claro) não tem acesso ao seu ssh-agent.
O ssh-agent é usado conforme abaixo:
$ ssh-agent
SSH_AUTH_SOCK=/tmp/ssh-XXvknpQ6/agent.23799; export
SSH_AUTH_SOCK;
SSH_AGENT_PID=23800; export SSH_AGENT_PID;
echo Agent pid 23800; 
A saída do ssh-agent foi feita para ser examinada pelo seu shell para acrescentar as 
variáveis de ambiente apropriadas. Ou copie e cole a saída na mesma janela de 
terminal, ou execute algo assim (assumindo que você está usando um shell bash):
bash$ eval `ssh-agent`
Agent pid 23800;
O ssh-agent está agora rodando e as variáveis de ambiente apropriadas foram 
configuradas de forma que o ssh e os vários utilitários ssh podem agora acessar o 
mesmo. Uma vez que o agente esteja rodando você pode acrescentar suas chaves 
privadas com comandos semelhantes ao abaixo:
$ ssh-add
Need passphrase for /home/acc/.ssh/identity
Enter passphrase for acc@debian-server
Identity added: /home/acc/.ssh/identity (acc@debian-server)
Agora, quando você fizer um ssh a um servidor remoto que está configurado para 
aceitar sua chave, você não precisa fornecer uma senha, você simplesmente faz a 
conexão. Obviamente, neste ponto você precisa ser extremamente cuidadoso sobre 
deixar pessoas que não são de confiançausar sua sessão de login (ssh-add -D faz o 
ssh-agent esquecer a senha se você precisar deixar o computador).
scp
O método tradicional de transferência de arquivos de uma máquina para outra por 
uma rede é usando o protocolo FTP. O FTP, como o IMAP e outros, transfere as 
informações de autenticação em texto plano, que pode não ser desejável. 
Infelizmente, devido à estrutura do protocolo FTP, é muito difícil fazer um tunel para 
o mesmo através de uma conexão ssh.
23
A P O S T I L A
D E
G N U / L I N U X
O SSH vem com um programa chamado 'scp', que significa 'secure copy' (cópia 
segura). Ele vem bem a calhar quando você quer transferir arquivos de um 
computador para outro de forma segura (ele também pode usar compressão se você 
usar a opção -C, que é boa para transferência de teto ou outro formato de dado que 
pode ser comprimido). Ele não usa um protocolo separado, mas envia os dados 
através de uma conexão ssh normal, e por isso ele aceita authorized_keys e 
conversa com o ssh-agent.
O uso do scp é bem simples. A sintaxe é:
scp file1 file2 file3 ... destination
Cada um dos argumentos pode ser um arquivo local ou remoto. Por exmeplo, pra 
compiar seu arquivo .bashr do servidor vacuum para o computador local:
$scp vacuum:.bashrc .
vacuum:.bashrc é a sintaxe que você usa para copiar de ou para um host remoto - 
host:arquivo. Se você não especificar um diretório, ele utiliza por padrão o diretório 
home. O destino é dado como ".", que significa o diretório atual.
24
A P O S T I L A
D E
G N U / L I N U X
5. SERVIDOR SAMBA
O Samba é o servidor que permite compartilhar arquivos e acessar 
compartilhamentos em máquinas Windows. Ele é dividido em dois módulos, o 
servidor Samba propriamente dito e o smbclient, que permite acessar 
compartilhamentos em outras máquinas. Usando o Samba, o servidor Linux se 
comporta exatamente da mesma forma que uma máquina Windows, compartilhando 
arquivos e impressoras e executando outras funções, como autenticação de 
usuários. Você pode configurar o Samba até mesmo para tornar-se um controlador 
de domínio.
A primeira versão do Samba, disponibilizada em 1992, foi escrita por Andrew 
Tridgell, um Australiano que na época era estudante de ciências da computação. 
Como na época a especificação do SMB utilizada pela Microsoft ainda era fechada, 
Andrew desenvolveu um pequeno programa, batizado de clockspy, para examinar os 
pacotes de dados enviados por uma máquina Windows e assim ir implementando 
uma a uma as chamadas de sistema utilizadas, um trabalho extremamente 
complexo para ser feito por uma única pessoa.
O resultado foi um programa que rodava no Solaris e era capaz de responder às 
chamadas SMB como se fosse um servidor Windows. Este arquivo ainda pode ser 
encontrado em alguns dos FTPs do http://samba.org, com o nome "server-0.5".
O objetivo desta primeira versão era apenas resolver um problema doméstico, 
interligar um PCrodando o Windows 3.1 ao servidor Solaris. Na época isso já era 
possível utilizando um dos clientes NFS comerciais para DOS, mas Andrew 
precisava de suporte a NetBIOS para um aplicativo que pretendia utilizar, o WindX, 
um servidor X para Windows, que permitia rodar aplicativos via rede a partir do 
servidor Unix.
Até aí o objetivo era apenas fazer o programa funcionar, não criar um sistema de 
compartilhamento de arquivos.
Depois de algum tempo Andrew recebeu um e-mail contando que o programa 
também funcionava com o LanManager da Microsoft, permitindo compartilhar 
arquivos de um servidor Unix com máquinas rodando o DOS. Andrew só acreditou 
depois de testar, mas ficou tão maravilhado com o que havia conseguido que criou o 
25
A P O S T I L A
D E
G N U / L I N U X
projeto "NetBios for Unix", e começou a recrutar voluntários através da Usenet. Mais 
tarde o projeto passou a usar o nome Samba, que foi adotado não em apologia ao 
Carnaval, mas apenas porque é uma das poucas palavras do dicionário do Aspell 
que possui as letras S, M e B, de "Server Message Blocks".
Em 94 a Microsoft liberou as especificações do SMB e do NetBios, o que permitiu 
que o desenvolvimento do Samba desse um grande salto, tanto em recursos quanto 
em compatibilidade, passando a acompanhar os novos recursos adicionados ao 
protocolo da Microsoft, que novamente deixou de ser aberto.
Hoje, além de ser quase 100% compatível com os recursos de rede do Windows 98, 
NT e 2000, o Samba é reconhecido por ser mais rápido que o próprio Windows na 
tarefa de servidor de arquivos.
Um dos pontos fortes do Samba é que o projeto foi todo desenvolvido sem precisar 
apelar para qualquer violação de patentes. Todas as chamadas (com exceção das 
que a Microsoft tornou públicas em 94) foram implementadas monitorando as 
transmissões de dados através da rede, uma espécie de engenharia reversa que 
não tem nada de ilegal. É como se você descobrisse como funciona um código de 
encriptação apenas examinando arquivos encriptados por ele. Matemáticos fazem 
isso a todo instante e muitas vezes são bem pagos para isso.
Graças a este "detalhe", o Samba não corre o perigo de sofrer restrições devido a 
ações judiciais. Naturalmente já houveram problemas legais com a Microsoft, cujo 
resultado apenas confirmou esta invulnerabilidade.
De qualquer forma, não existem sinais de que a Microsoft pretenda declarar guerra 
ao Samba, pelo contrário, foi a existência do Samba que permitiu que a Microsoft 
conseguisse colocar PCs rodando o Windows em muitos nichos onde só entravam 
Workstations Unix, já que com o Samba os servidores Unix existentes passaram a 
ser compatíveis com as máquinas Windows. Ou seja, de certa forma o Samba é 
vantajoso até mesmo para a Microsoft.
5.1 Instalando o Samba
O Samba é dividido em dois módulos. O servidor propriamente dito e o cliente, que 
permite acessar compartilhamentos em outras máquinas (tanto Linux quanto 
Windows). Os dois são independentes, permitindo que você mantenha apenas o 
cliente instalado num desktop e instale o servidor apenas nas máquinas que 
realmente forem compartilhar arquivos. Isto permite melhorar a segurança da rede 
de uma forma geral.
Para instalarmos o servidor do Samba, será necessário o seguinte comando:
# apt-get install samba samba-doc swat
26
A P O S T I L A
D E
G N U / L I N U X
Lembre-se de que você deve instalar todos os pacotes apenas no servidor e em 
outras máquinas que forem compartilhar arquivos. O Swat ajuda bastante na etapa 
de configuração, mas ele é opcional, pois você pode tanto editar manualmente o 
arquivo smb.conf, quanto usar um arquivo pronto, gerado em outra instalação. Nos 
clientes que forem apenas acessar compartilhamentos de outras máquinas, instale 
apenas o cliente.
5.2 Cadastrando usuários.
Depois de instalado, o próximo passo é cadastrar os logins e senhas dos usuários 
que terão acesso ao servidor. Esta é uma peculiaridade do Samba: ele roda como 
um programa sobre o sistema e está subordinado às permissões de acesso deste. 
Por isso ele só pode dar acesso para usuários que, além de estarem cadastrados no 
Samba, também estão cadastrados no sistema.
Existem duas abordagens possíveis. Você pode criar usuários "reais" usando o 
comando adduser ou um utilitário como o "user-admin" (disponível no Fedora e no 
Debian, através do pacote gnome-system-tools). Ao usar o adduser, o comando fica: 
# adduser maria
Uma segunda opção é criar usuários "castrados", que terão acesso apenas ao 
Samba. Esta abordagem é mais segura, pois os usuários não poderão acessar o 
servidor via SSH ou Telnet, por exemplo, o que abriria brecha para vários tipos de 
ataques. Neste caso, você cria os usuários adicionando os parâmetros que orientam 
o adduser a não criar o diretório home e manter a senha desativada até segunda 
ordem:
# adduser --disabled-login --no-create-home maria 
Isto cria uma espécie de usuário fantasma que, para todos os fins, existe e pode 
acessar arquivos do sistema (de acordo com as permissões de acesso), mas, por 
outro lado, não pode fazer login (nem localmente, nem remotamente via SSH), nem 
possui diretório home.
De qualquer uma das duas formas, depois de criar os usuários no sistema, você 
deve cadastrá-los no Samba, usando o comando "smbpasswd -a", como em:
# smbpasswd -a maria
Se você mantiver os logins e senhas sincronizados com os usados pelos usuários 
nos clientes Windows, o acesso aos compartilhamentos é automático. Caso os 
logins ou senhas no servidor sejam diferentes, o usuário precisará fazer login ao 
acessar.
27
A P O S T I L A
D E
G N U / L I N U X
Um detalhe importante é que, ao usar clientes Windows 95 ou 98, você deve marcar 
a opção de login como "Login do Windows" e não como "Cliente para redes 
Microsoft" (que é o default) na configuração de rede (Painel de controle > Redes).
Depois de criados os logins de acesso, falta agora apenas configurar o Samba para 
se integrar à rede e compartilhar as pastas desejadas; trabalho facilitado pelo Swat. 
A segunda opção é editar manualmente os arquivos de configuração do Samba, o 
"/etc/samba/smb.conf", como veremos mais adiante. Neste caso, o ideal é começar 
a partir de um arquivo pré-configurado, alterando apenas as opções necessárias.
5.3 Configurando o Samba usando o Swat
O Samba pode ser configurado através do Swat, um utilitário de configuração via 
web, similar ao encontrado nos modems ADSL. Isso permite que ele seja acessado 
remotamente e facilita a instalação em servidores onde o X não está instalado. Esta 
mesma abordagem é utilizada por muitos outros utilitários, como o Webmin e o 
Pagode.
Manter o X instalado e ativo num servidor dedicado é considerado um desperdício 
de recursos, por isso os desenvolvedores de utilitários de configuração evitam 
depender de bibliotecas gráficas. Deste modo, mesmo distribuições minimalistas 
podem incluí-los. 
No Debian, Slackware e também no Gentoo, o Swat é inicializado através do inetd. A 
função do inetd e xinetd é parecida, eles monitoram determinadas portas TCP e 
carregam serviços sob demanda. Isto evita que utilitários que são acessados 
esporadicamente (como o Swat) precisem ficar ativos o tempo todo, consumindo 
recursos do sistema. Apesar disso, a configuração dos dois é diferente: no caso das 
distribuições que usam o inetd, você ainda precisa adicionar (ou descomentar) a 
linha abaixo no arquivo de configuração do inetd, o "/etc/inetd.conf":
swat stream tcp nowait.400 root /usr/sbin/tcpd /usr/sbin/swat
Para que a alteração entre em vigor, reinicie o inetd com o comando:
# /etc/init.d/inetd restart
Para acessar o Swat, basta abrir um Browser disponível e acessar oendereço 
http://localhost:901 . No prompt de login, forneça a senha de root para acessar.
Ao abrir o Swat, você verá um menu com vários links para a documentação 
disponível sobre o Samba, que você pode consultar para se aprofundar no sistema. 
Na parte de cima, estão os links para as seções da configuração, que é o que nos 
interessa.
28
A P O S T I L A
D E
G N U / L I N U X
Na seção Password, você pode cadastrar usuários, substituindo o uso manual do 
comando "smbadduser -a". Neste caso, você precisará primeiro cadastrar os 
usuários utilizando comando adduser; o Swat apenas cadastra os usuários no 
Samba.
Em seguida, acesse a seção "Globals", que engloba todas as configurações de rede 
e acesso.
Nas opções "workgroup" e "netbios name", você deve colocar o nome do 
29
A P O S T I L A
D E
G N U / L I N U X
computador e o grupo de trabalho a que ele pertence, como faria numa máquina 
Windows. Você pode tanto utilizar o mesmo grupo de trabalho em todas as 
máquinas da rede, quanto agrupar suas máquinas em grupos distintos como 
"diretoria", "vendas", etc.
A opção "netbios aliases" permite criar "apelidos" para o servidor, de modo de que 
ele possa ser acessado por mais de um nome. Usando um alias, o servidor 
realmente aparece duas vezes no ambiente de rede, como se fossem duas 
máquinas. Em geral isso acaba confundindo mais do que ajudando, mas pode ser 
útil em algumas situações, quando, por exemplo, um servidor é desativado e os 
compartilhamentos movidos para outro. O novo servidor pode responder pelo nome 
do servidor antigo, permitindo que os usuários que não foram avisados da mudança 
continuem acessando os compartilhamentos.
A seguir temos a opção "interfaces", que permite limitar os acessos ao servidor se 
você tiver mais de uma placa de rede. É o caso, por exemplo, de quem acessa via 
ADSL ou cabo e possui uma segunda placa de rede para compartilhar a conexão 
com os micros da rede local. Nestes casos a placa da web será reconhecida como 
eth0, enquanto a placa da rede local será reconhecida como eth1, por exemplo.
Você pode, então, preencher o campo com o endereço da placa da rede local (eth1), 
assim o Samba só aceitará conexões vindas dos micros da rede local, descartando 
automaticamente todas as tentativas de acesso vindas da internet. Caso o campo 
permaneça vazio, o Samba permite acessos vindos de todas as placas de rede, e é 
necessário bloquear os acessos provenientes da internet usando o firewall.
30
A P O S T I L A
D E
G N U / L I N U X
Na seção Security Options chegamos a uma das decisões mais importantes, decidir 
entre entre utilizar segurança com base no login do usuário (user) ou com base no 
compartilhamento (share).
A opção share oferece um nível de segurança semelhante ao de uma máquina 
Windows 98. Os compartilhamentos podem ser acessados por todos os usuários, 
através da conta guest. Em compensação, esta opção é a mais simples de 
configurar e pode ser útil em pequenas redes onde não há necessidade de 
segurança.
A opção user é a mais recomendável, pois permite especificar exatamente quais 
usuários terão acesso a cada compartilhamento, como num servidor NT ou Windows 
2000. Naturalmente, para que isso funcione, é necessário que você tenha registrado 
todos os usuários no Linux e no Samba (como vimos anteriormente), e que os 
clientes Windows efetuem login na rede usando estes mesmos logins e senhas, ou 
os forneçam na hora de acessar os compartilhamentos.
Escolhendo este modo, as permissões de acesso aos compartilhamentos do samba 
ficam condicionadas às permissões de acesso de cada usuário. Por exemplo, se 
você compartilhar a pasta /home/maria/arquivos, por default apenas a usuária maria 
terá permissão para gravar novos arquivos e alterar o conteúdo da pasta.
Para que outros usuários tenham acesso à pasta, você deve dar permissão a eles, 
criando um novo grupo e dando permissão de escrita para os integrantes do grupo 
ou adicionando os demais usuários no grupo "maria" (que é criado juntamente com o 
login de acesso) e configurando as permissões de acesso de forma que o grupo 
possa escrever na pasta.
Se você não está tão preocupado com a segurança, pode fazer do jeito "fácil", 
alterando a opção "outros" nas permissões de acesso da pasta, que dá acesso a 
todo mundo. Isto faz com que qualquer usuário local do sistema (ou logado via SSH) 
tenha acesso aos arquivos da pasta, mas não permite necessariamente que outros 
usuários do Samba possam acessar, pois neste caso ainda são usadas as 
permissões de acesso no Samba.
Ou seja, é necessário fazer com que os usuários do grupo, ou todos os usuários do 
sistema possam escrever na pasta, evitando que as permissões do sistema 
conflitem com as permissões configuradas no Samba. Se configuro o Samba para 
permitir que o usuário "joao" possa escrever no compartilhamento, mas a 
configuração das permissões da pasta compartilhada não permitem isso, o Joao vai 
continuar sem conseguir escrever. Ao criar compartilhamentos no Samba, é preciso 
se preocupar com as duas coisas.
 
Mais abaixo, temos a opção Encrypt Password. Ela também é importantíssima, e 
deve ser configurada de acordo com a versão do Windows que rodar nas máquinas 
31
A P O S T I L A
D E
G N U / L I N U X
clientes. O Windows 95 original não suporta encriptação de senhas, por isso só 
poderá se conectar ao servidor caso a opção seja configurada com o valor "No". 
Porém, o Windows 95 OSR/2, Windows 98/SE/ME, Windows NT, Windows 2000 e 
Windows XP utilizam senhas encriptadas, então, ao utilizar máquinas com qualquer 
um destes sistemas (que é o mais provável) a opção deve ser configurada como 
"Yes", caso contrário o Samba simplesmente não conseguirá conversar com as 
máquinas Windows.
A partir do Samba 3 existe a opção de fazer com que o próprio Samba mantenha as 
senhas dos usuários sincronizadas em relação às senhas dos mesmos no sistema. 
Antigamente, sempre que você alterava a senha de um usuário no Samba, usando o 
"smbpasswd", precisava alterar também a senha do sistema, usando o comando 
"passwd". As duas senhas precisam ficar em sincronismo, do contrário caímos no 
problema das permissões, onde o Samba permite que o usuário acesse o 
compartilhamento, mas o sistema não permite que o Samba acesse os arquivos no 
disco.
Para ativar este recurso, ative a opção "unix password sync" no Swat. Originalmente, 
esta opção fica desativada e aparece apenas dentro das opções avançadas. Para 
chegar até ela você deve clicar no botão "Change View To: Advanced" no topo da 
tela. Depois de alterar, clique no Commit Changes".
Para que tudo funcione, é necessário que as opções "passwd program" e "passwd 
chat" estejam configuradas com (respectivamente) os valores: "/usr/bin/passwd %u" 
e "*Enter\snew\sUNIX\spassword:* %n\n *Retype\snew\sUNIX\spassword:* %n\n .". 
Estes já são os valores padrão no Swat, mas não custa verificar.
32
A P O S T I L A
D E
G N U / L I N U X
A opção "Hosts Allow" deve incluir os endereços IP de todos os computadores que 
terão permissão para acessar o servidor. Se quiser que todos os micros da rede 
tenham acesso, basta escrever apenas a primeira parte do endereço IP, como em 
"192.168.0.", onde todos os endereços dentro do escopo serão permitidos. Se for 
incluir mais de um endereço ou mais de um escopo de endereços, separe-os por um 
espaço, como: "192.168.0., 10.0.0., 123.73.45.167". Caso o campo permaneça 
vazio, a opção fica desativada, e todos os micros que tiverem acesso ao servidor 
Samba poderão acessar.
A opção "Hosts Deny" por sua vez permite especificar máquinas que não terão 
permissãopara acessar o servidor. Você pode usar o Hosts Deny para estabelescer 
exceções ao dito na opção Hosts Allow.
Por exemplo, imagine que você queira que toda a rede local, que usa a faixa 
33
A P O S T I L A
D E
G N U / L I N U X
192.168.0.x, tenha acesso ao servidor, com exceção dos endereços 192.168.0.2 e 
192.168.0.3. Neste caso, a configuração ficaria assim:
Hosts Allow: 192.168.0.
Hosts Deny: 192.168.0.2, 192.168.0.3
Numa rede Windows, uma das máquinas fica sempre responsável por montar e 
atualizar uma lista dos compartilhamentos disponíveis e enviá-la aos demais, 
conforme solicitado. O host que executa esta função é chamado de "Master 
Browser".
Na seção Browse Options, a opção "OS Level" permite especificar qual chance o 
servidor Linux terá de ser o Master Browser do grupo de trabalho ou domínio. 
Sempre que você estiver configurando o Samba para ser o servidor principal, é 
desejável que ele seja o master browser.
Para isso, configure esta opção com um valor alto, 100 por exemplo, para que ele 
sempre ganhe as eleições. O default dessa opção é 20, que faz com que ele perca 
para qualquer máquina Windows NT, Windows 2000 ou Windows XP. Para 
completar, deixe a opção "Local Master" e "Preferred Master" como "Yes".
A configuração do OS Level é muito importante. Caso não seja o Master Browser, 
você poderá ter problemas para acessar seu servidor Linux a partir de outras 
máquinas Windows, principalmente rodando o NT/2000/XP. Com o valor 100, 
sempre que uma das máquinas Windows tentar ser o Master Browser da rede, o 
Samba convocará uma nova eleição e a máquina Linux sempre ganhará.
Abaixo, deixe a opção Wins Support ativada (Yes). A opção Wins Server deve ser 
deixada em branco, a menos que exista na rede algum servidor Wins (rodando o NT 
server ou o 2K server) ao qual o servidor Linux esteja subordinado. 
Caso o único servidor seja a máquina Linux, você pode configurar as máquinas 
34
A P O S T I L A
D E
G N U / L I N U X
Windows para utilizá-la como servidor Wins, para isto basta colocar o seu endereço 
IP no campo "Servidor Wins" na configuração de rede das estações.
Terminando, pressione o botão "Commit Changes" no topo da tela para que as 
alterações sejam salvas no arquivo "/etc/samba/smb.conf". 
Uma observação importante é que o Swat lê o arquivo smb.conf ao ser aberto, lendo 
as opções configuradas e mostrando-as na interface, mas gera um novo arquivo 
sempre que você clica no "Commit Changes". Ao ler o arquivo, ele procura por 
trechos específicos de texto, ignorando tudo que for diferente. Isso faz com que ele 
remova qualquer tipo de comentário incluído manualmente no arquivo. Em geral, 
quem tem o hábito de editar manualmente o smb.conf, acaba nunca usando o Swat 
e vive-versa.
Depois de cadastrar os usuários no sistema e no Samba e configurar a seção 
Globals, falta apenas configurar as pastas que serão compartilhadas com as 
estações, através da seção "Shares".
Cada usuário válido cadastrado no sistema possui automaticamente um diretório 
home. Estas pastas ficam dentro do diretório /home e podem ser usadas para 
guardar arquivos pessoais, já que, a menos que seja estabelecido o contrário, um 
usuário não terá acesso à pasta pessoal do outro. Além dos diretórios home, você 
pode compartilhar mais pastas de uso geral.
Para criar um compartilhamento, basta escrever seu nome no campo no topo da tela 
e clicar no botão "Create Share".
Depois de criado um compartilhamento, escolha-o na lista e clique no botão "Choose 
35
A P O S T I L A
D E
G N U / L I N U X
Share" para configurá-la. Você verá uma lista de opções, contendo campos para 
especificar usuários válidos e inválidos, usuários que podem ou não escrever no 
compartilhamento, nomes ou endereços de máquinas entre outras opções.
O campo "path" é o mais importante, pois indica justamente qual pasta do sistema 
será compartilhada. O nome do compartilhamento diz apenas com que nome ele 
aparecerá no ambiente de rede, que não precisa necessariamente ser o mesmo 
nome da pasta.
A opção "comment" permite que você escreva um breve comentário sobre a pasta 
que também poderá ser visualizado pelos usuários no ambiente de rede. Este 
comentário é apenas para orientação, não tem efeito algum sobre o 
compartilhamento.
A opção "read only" determina se a pasta ficará disponível apenas para leitura 
(opção Yes) ou se os usuários poderão também gravar arquivos (opção No). Você 
pode também determinar quais máquinas terão acesso ao compartilhamento através 
das opções "Hosts Allow" e "Hosts Deny". As configurações feitas aqui subscrevem 
as feitas na seção global. Se, por exemplo, a máquina 192.168.0.5 possui permissão 
36
A P O S T I L A
D E
G N U / L I N U X
para acessar o sistema, mas foi incluída na campo Hosts Deny do compartilhamento 
programas, ela poderá acessar outros compartilhamentos do sistema, mas não o 
compartilhamento programas especificamente.
A opção "browseable" permite configurar se o compartilhamento aparecerá entre os 
outros compartilhamentos do servidor no ambiente de rede, ou se será um 
compartilhamento oculto, que poderá ser acessado apenas por quem souber que ele 
existe. Isso tem uma função semelhante a colocar um "$" numa pasta compartilhada 
no Windows 98. Ela fica compartilhada, mas não aparece no ambiente de rede. 
Apenas usuários que saibam que o compartilhamento existe conseguirão acessá-lo. 
Esta opção tem efeito apenas sobre os clientes Windows, pois no Linux a maior 
parte dos programas clientes (como o Smb4k) mostram os compartilhamentos 
ocultos por padrão.
Finalmente, a opção "available" especifica se o compartilhamento está ativado ou 
não. Você pode desativar temporariamente um compartilhamento configurando esta 
opção como "No". Fazendo isso, ele continuará no sistema e você poderá torná-lo 
disponível quando quiser, alterando a opção para "Yes".
Um detalhe importante é que os usuários só terão permissão para acessar pastas 
que o login permite acessar. Por exemplo, no Linux o único usuário que pode 
acessar a pasta /root é o próprio root, ou outro autorizado por ele. Mesmo que você 
compartilhe a pasta root através do Samba, os demais usuários não poderão 
acessá-la.
Para editar as permissões de uma pasta, basta abrir o gerenciador de arquivos e, 
nas propriedades da pasta, acessar a guia "Permissões". As permissões podem ser 
dadas apenas ao usuário, para todos os usuários pertencentes ao grupo do usuário 
dono da pasta, ou para todos os usuários. A opção "Aplicar mudanças a todas as 
subpastas e seus conteúdos" deve ficar marcada para que as permissões sejam 
aplicadas também às subpastas.
Terminadas as configurações, o servidor já irá aparecer no ambiente de rede, como 
se fosse um servidor Windows. Os compartilhamentos podem ser acessados de 
acordo com as permissões que tiverem sido configuradas, mapeados como 
unidades de rede, entre outros recursos.
Para compartilhar uma impressora já instalada na máquina Linux, o procedimento é 
o mesmo. Dentro do Swat, acesse a seção printers, escolha a impressora a ser 
compartilhada (a lista mostrará todas as instaladas no sistema), configure a opção 
available como "yes" e configure as permissões de acesso como vimos 
anteriormente.
5.4 Configurando o Samba manualmente - /etc/samba/smb.conf
Toda a configuração do Samba, incluindo as configurações gerais do servidor, 
37
A P O S T I L A
D E
G N U / L I N U X
impressoras e todos os compartilhamentos, é feita num único arquivo de 
configuração, o "/etc/samba/smb.conf". Programas de configuração,como o Swat, 
simplesmente lêem este arquivo, "absorvem" as configurações atuais e depois 
geram o arquivo novamente com as alterações feitas.
Isto permite que o Swat coexista com a edição manual do arquivo. Como o formato é 
bastante simples e conciso, muitas vezes é mais rápido e até mais simples editar 
diretamente o arquivo do que através do Swat.
O smb.conf possui as mesmas seções mostradas no swat: global, homes, printers, 
etc.
Para iniciar a edição do arquivo de configuração do smb.conf utilisamos o seguinte 
comando:
# vi /etc/samba/smb.conf
Confira abaixo um exemplo do smb.conf e em seguida a explicaçao de cada 
parâmetro presente nas seçoes: 
[global]
 comment = Servidor SAMBA
 workgroup = EMPRESA
 security = user
 os level = 100
 announce as = NT Server
 domain logons = yes
 logon script = %U.bat
 logon path = \\%L\Profiles\%U
 domain master = yes
 local master = yes
 preferred master = yes
 guest account = nobody
 # wins server = 192.168.0.2
 wins support = yes
 keep alive = 20
 debug level = 3
 winpopup command = csh -c ''xedit %s;rm %s'' &
 log file = /var/log/samba_log.%u
 null passwords = no
 unix password sync = yes
 socket options = IPTOS_LOWDELAY TCP_NODELAY
 printing = bsd
 printcap name = /etc/printcap
38
A P O S T I L A
D E
G N U / L I N U X
 load printers = yes
 hosts allow = 192.168.0. 127.
 hosts deny = 192.168.0.3 192.168.0.4
 [homes]
 comment = Pastas dos Usuarios 
 public = no 
 browseable = yes 
 writeable = yes 
 hosts deny = 192.168.0.250
 [printers] 
 comment = Impressoras Linux
 public = no
 browseable = yes
 printable = yes
 read only = yes
 create mode = 0700 
 path = /var/spool/samba 
 admin users = admin, usuario1
 [netlogon] 
 comment = Compartilhamento de Scripts
 path = /etc/scripts 
 public = no 
 browseable = yes
 writeable = no
 [diretoria] 
 comment = Grupo Diretoria
 path = /home/diretoria
 public = no 
 browseable = yes
 writeable = yes 
 write list = @diretoria
 force create mode = 0777
 force directory mode = 0777
 [comercial] 
 comment = Grupo Comercial
 path = /home/comercial
 public = yes
 browseable = yes
39
A P O S T I L A
D E
G N U / L I N U X
 writeable = yes
 write list = @comercial
 read list = @marketing
 force create mode = 0777
 force directory mode = 0777
 [transf]
 comment = Area de Transferencia
 path = /home/transf
 public = yes
 browseable = yes
 writeable = yes
 write list = @todos
 force create mode = 0777
 force directory mode = 0775
 max disk size = 200
 [oculto$]
 comment = Especifico do Admin
 path = /home/admin/oculto
 copy = homes max connections = 1
Parâmetros Funçoes
comment Comentário para este Host na Rede.
workgroup Especifica o Domínio ou Workgroup a que o Host pertence na Rede.
security
Por padrao o SAMBA utiliza a segurança a nível de usuário 
(security = user), mas existem outras opçoes:
security = share -> Senhas de acesso serao solicitadas por 
cada recurso compartilhado e nao por usuário, ou seja, 
cada diretório ou impressora poderá ter uma senha única 
conhecida pelos usuários autorizados.
security = user -> As permissoes sao dadas de acordo 
com o login do usuário, ou através dos grupos (@grupo).
security = server -> O SAMBA tentará validara senha do 
usuário enviando os dados para outro servidor SMB, como 
outro servidor SAMBA ou um servidor Windows. Deve-se 
incluir o parâmetro .password server = x.x.x.x. na seçao 
[global] do smb.conf.
security = domain -> Usado se o Host for adicionado a um 
40
A P O S T I L A
D E
G N U / L I N U X
Domínio Windows através do comando smbpasswd. Neste 
caso as informaçoes de usuário e senha serao enviadas 
para o PDC da rede, exatamente como o servidor NT faria. 
Note que é necessário que a conta do usuário exista tanto 
no Linux quanto no servidor primário.
os level
Este parâmetro nao é obrigatório se voce nao possui um 
servidor Windows na rede, mas deve ser usado caso tenha 
um ou mais. A variável é um número de 1 a 255, onde 65 é 
a mesma variável utilizada pelo servidor Windows. 
Especifique um número maior que este (como 100 por 
exemplo) para garantir que o servidor SAMBA seja eleito na 
escolha de validaçao do login das estaçoes.
announce as
Permite especificar o tipo de servidor NetBios (nmbd) que 
será divulgado na rede. As opçoes aceitas pelo SAMBA: 
"NT Server", "NT Workstation", "Win95" ou "WfW".
domain logons Usado para validar o login na rede, apenas para estaçoes Windows.
logon script
Indica qual arquivo de logon script será executado para os 
usuários. A variável %u corresponde ao usuário na rede. 
Deve também ser criado um compartilhamento de nome 
[netlogon] apontando para o diretório dos scripts.
logon path
Indica o caminho do perfil remoto do usuário. A variável %L 
corresponde ao nome do servidor NetBios (que pode ser o 
próprio SAMBA). O logon path é útil quando usuários 
costumam efetuar logon em mais de um Host na rede, pois 
seu perfil é trazido com o logon. No caso do exemplo, o 
diretório "Profiles" deve conter os scripts (em formato 
Microsoft usando NET USE e etc) e os scripts devem ser 
criados com o notepad do Windows por exemplo, a fim de 
conservar o formato do arquivo.
domain master Indica se o Host será o Domain Master Browser da rede inteira (WAN).
local master Indica se o Host será o Master Browser da rede local.
preferred master
Este parâmetro força a eleiçao do SAMBA como Master 
Browser para o workgroup. É recomendável utilizar este 
parâmetro em conjunto com o .domain master = yes. para 
garantir a eleiçao. Mas tome cuidado: se voce possui uma 
rede com servidores Windows e SAMBA e já possui um 
41
A P O S T I L A
D E
G N U / L I N U X
servidor como Domain Master, nao use esta opçao e deixe 
o parâmetro .os level = 65. para haver equilíbrio.
guest account
O SAMBA trabalha melhor em redes Microsoft com a 
existencia de uma conta guest (visitante em ingles). Por 
padrao a conta usada é .nobody.
wins server
Indica qual o servidor de Wins da rede. Se o próprio Host 
for o servidor de Wins entao nao utilize este parâmetro, pois 
haverá um loop e o sistema travará!
wins support
Permite ao SAMBA ser o servidor de Wins na rede. Isto 
significa que o SAMBA terá uma tabela com o ambiente 
completo da rede, garantindo que as estaçoes tenham 
acesso a estas informaçoes e ganho em velocidade para 
encontrar e acessar os compartilhamentos e impressoras. O 
Wins Server deve ser especificado na configuraçao de rede 
(TCP/IP) das estaçoes, que é o endereço IP do servidor.
keep alive
Como máquinas rodando Windows tendem a travar de 
tempos em tempos, este parâmetro é usado para verificar o 
estado da conexao, evitando tráfego desnecessário na 
rede. Também pode ser usado para estaçoes Linux.
debug level
Parâmetro usado para dar flexibilidade a configuraçao do 
sistema. Permite ao SAMBA trabalhar corretamente com 
algumas situaçoes de erro, por exemplo.
winpopup command
Especifica qual commando será executado quando o 
servidor receber mensagens Winpopup. Aqui, muitas 
opçoes podem ser usadas de acordo com a preferencia do 
Administrador. Se sua rede utiliza mensagens deste tipo, é 
interessante definir um comando para o parâmetro, evitando 
assim possíveis mensagens de erro para quem enviou a 
mensagem ao servidor.
log file Indica o arquivo de log do SAMBA. A variável %u corresponde ao nome de logon do usuário.
null passwords Indica se será ou nao possível que usuários tenham senha nula de logon (logon sem senha).
unix password sync
Se este parâmetro for ativado (= yes) entao clientes SMB 
(como estaçoes Windows) poderao trocarsua senha de 
login.
socket options Este parâmetro permite configuraçoes extras para o 
42
A P O S T I L A
D E
G N U / L I N U X
protocolo, possibilitando uma melhor performance do 
servidor em lidar com os pacotes na rede.
printing Indica qual o sistema de impressao padrao utilizado pelo Linux.
printcap name Indica o arquivo para busca das definiçoes das impressoras.
load printers Disponibiliza as impressoras para a rede.
hosts allow 
Indica quais máquinas tem acesso ao servidor SAMBA. 
Pode-se utilizar o endereço IP ou o nome da máquina. Para 
garantir acesso a toda uma rede por exemplo, escreva: 
"hosts allow = 192.168.1.".
hosts deny Como em "hosts allow", mas para restringir o acesso ao servidor SAMBA.
A seçao [homes] define os parâmetros para as pastas pessoais dos usuários na rede 
(home dir):
Parâmetros Funçoes
comment Comentário para este compartilhamento.
public Também conhecido como .guest ok., permite ou nao acesso de outros usuários.
browseable
Define se o compartilhamento será ou nao visível para o 
Ambiente de Rede. Estaçoes Windows95 versao 4.00.950-
C nao aceitam esta opçao, onde uma possível soluçao é 
utilizar o nome do compartilhamento seguido de $ (teste$ 
por exemplo), como faz-se no Windows.
writeable Indica se o usuário poderá ou nao ecrever em sua pasta pessoal (home dir).
As demais seçoes correspondem a compartilhamentos presentes na rede. Os 
parâmtros abaixo sao apenas alguns dos possíveis:
Parâmetros Funçoes
comment Comentário para o compartilhamento.
43
A P O S T I L A
D E
G N U / L I N U X
path Caminho do diretório compartilhado
writeable Indica se será ou nao possível criar ou excluir arquivos ou diretórios do compartilhamento.
public / guest ok Indica se será ou nao permitido o acesso de outros usuários.
browseable Define se o compartilhamento será ou nao visível para o Ambiente de Rede.
write list
Define os usuários e/ou grupos com acesso de escrita no 
compartilhamento. Para mais de um usuário, separe os 
nomes por vírgula (user1, user2, etc) e para grupos utilize 
@ antes do nome do grupo.
read list Como em .write list., mas define quem terá permissao de apenas leitura.
force create mode
Diz ao SAMBA para forçar o tipo de permissao dos arquivos 
criados (o mesmo que usar o chmod). Esta permissao tem 
menor prioridade que os parâmetros .write list. e .read list..
force directory mode O mesmo que .force create mode., mas para os diretórios criados no compartilhamento.
admin users Indica quais sao os usuários com permissao completa para o compartilhamento (permissao de root).
copy
Permite copiar os parâmetros de outra seçao, como um 
template por exemplo, útil se utiliza compartilhamentos 
semelhantes. Para alterar parâmetros basta informá-los na 
seçao atual.
hosts allow
Indica quais máquinas podem acessar o compartilhamento. 
Pode-se utilizar o endereço IP ou o nome da máquina. Para 
garantir acesso a toda uma rede classe C por exemplo, 
escreva: "hosts allow = 192.168.1.".
hosts deny Como em "hosts allow", mas para restringir o acesso ao compartilhamento.
max connections Permite especificar o número máximo de conexoes simultâneas ao compartilhamento.
max disk size Permite especificar qual o limite de espaço em disco que o compartilhamento pode utilizar. Este valor é definido em Mb 
44
A P O S T I L A
D E
G N U / L I N U X
(megabytes).
A próxima apresenta variáveis que podem ser usadas em parâmetros:
Variáveis Funçoes
%S Nome do Serviço (compartilhamento) atual.
%u Nome do usuário.
%g Nome do grupo.
%H Nome do diretório pessoal do usuário (home dir).
%m Nome da máquina cliente fornecido pelo NetBios.
%L Nome do servidor NetBios, permitindo que a configuraçao desejada seja alterada de acordo com o cliente que vai acessar o sistema.
%M Nome Internet da máquina cliente.
%a Sistema Operacional da máquina remota, onde os reconhecidos sao WfW, WinNT e Win95.
%I O endereço IP da máquina cliente.
%T Data e horário.
Exemplo de um smb.conf básico para teste e implementação:
[global]
workgroup = Workgroup
server string = Samba server
;wins support = no
###debugging###
log file = /var/null
syslog only = no
security = share
guest account = nobody
[homes]
45
A P O S T I L A
D E
G N U / L I N U X
browseable = no
creat mask = 0700
directory mask = 0700
###file sharing###
[Compartilhado]
path =/mnt/hdb/mpl/ 
browseable = yes 
security = user 
public = yes 
writable = yes
5.5 O smbclient
Da mesma forma que o SAMBA permite que o Linux atue como servidor em redes 
Microsoft, ele também permite atuar como estaçao, sem que nenhuma configuraçao 
seja necessária no servidor Microsoft.
Com o smbclient é possível acessar dados em um servidor Windows (lembra o 
comando net da Microsoft, mas os comandos utilizados sao similares aos de FTP). 
Ele pode ser usado para receber e enviar arquivos, listar diretórios, navegar pelos 
diretórios, renomear e apagar arquivos, entre outros. Diretórios compartilhados por 
um servidor SAMBA sao acessados da mesma forma.
Para verificar quais compartilhamentos estao disponíveis em um determinado Host, 
execute:
#/usr/sbin/smbclient -L host_desejado
A resposta será uma lista de serviços, ou seja, nomes de dispositivos ou 
impressoras que podem ser compartilhados com os usuários na rede. A menos que 
o servidor SMB nao tenha itens de segurança configurados, será solicitada uma 
senha antes de mostrar as informaçoes. Exemplo:
#smbclient -L servidor1
A resposta será semelhante a:
Server time is Fri Dec 22 15:58:02 2000
Timezone is UTC+10.0 Password: Domain=[EMPRESA] OS=[Windows NT 
4.0] Server=[NT LAN Manager 4.0] Server=[servidor1] User=[] 
Workgroup=[EMPRESA] Domain=[] 
46
A P O S T I L A
D E
G N U / L I N U X
Sharename Type Comment 
ADMIN$ Disk Remote Administration Public Disk Public C$ Disk 
Default Share Print$ Disk Printer Control 
Para acessar uma pasta compartilhada, basta especificar o caminho na rede, 
conforme abaixo:
$smbclient //maquina/pasta1 senha
Onde "senha" é literalmente a senha de acesso. Se o caminho estiver correto a 
resposta será algo como:
Server time is Fri Dec 22 16:01:12 2000
Timezone is UTC+10.0
Domain=[EMPRESA] OS=[Windows NT 4.0] Server=[NT LAN Manager]
smb:\>
Digite help para obter ajuda sobre os comandos do smbclient.
47
A P O S T I L A
D E
G N U / L I N U X
6. SERVIDOR DNS BIND9
Boa parte da usabilidade da Internet vem da facilidade que temos para localizar um 
computador conectado. Apesar da maioria dos computadores só conseguirem 
localizar outros através de endereços IP, nós humanos podemos localizá-los 
facilmente através de um nome inteligível. É o que acontece, por exemplo, quando 
acessamos a página oficial do sistema operacional Linux através do nome 
www.linux.org, ao invés de precisarmos usar o número 198.182.196.56 que, cá entre 
nós, é bem mais feio. Esta conversão de nome para números é feita 
automaticamente através do mecanismo de DNS (sigla de Domain Name System).
Os administradores de rede gostam de colocar uns nomes um tanto quanto criativos 
nas suas máquinas. Alguns usam nomes de cidades da região em que a LAN está 
localizada (como Olinda, Buíque e Jaboatão). Outros gostam de usar nomes de 
personagens de quadrinhos como Mônica, Cebolinha, Cascão, Magali. Outros 
preferem nomes de grandes nomes da música brasileira como Raul Seixas, Elis 
Regina e Tom Jobim. Assim como o DNS é usado na Internet, pode também ser 
usado em uma rede interna para facilitar sua utilização. Isso permite, por exemplo 
que ao invés