Flavio Reis

Squid - parte 06

2009-02-09T18:09:00.000-08:00

Controle de banda

O squid oferece uam forma simples de gerenciar a banda disponível e definir o quanto cada usuário pode usar ( mantendo parte do link livre para os demais ), utilizando um recurso chamado “delay pools”. Imagine um link de 2 megabits para uma rede de 20 usuários. Se cada um puder ficar baixando o que quiser, é provável que a rede fique saturada em determinados horários, deixando a navegação lenta para todos usuários.

Pode-se evitar isso, limitando o uso da banda. É recomendado que o proxy (que combina todos os acessos via http) consuma um pouco menos do que a banda total, deixando uma parte para outros protocolos.

Um link de 2 mega (2048 kbits) corresponde a 262144 byes por segundo. Nas regras do squid, sempre usamos bytes por isso sempre temos que fazer a conversão.

Entendo a conversão

2 megabit são quantos bytes por segundo?

2048 k bits / s

2 megabit = 2048 kbits

agora em bytes

2 x 1024 = 2048 / 8 = 256 kbytes

Porque eu divido por 8?

Porque 1 byte = 8 bits

Mas eu quero em bytes...

256 kilobytes = 256 x 1024 bytes = 262144 bytes por segundo

O SQUID trabalha com bytes!!!

Como ficaria o cálculo para 3 megabits???

3 megabits = 3 x 1024 = 3072 / 8 = 384 kbytes x 1024 = 393216 bytes por segundo

Podemos então limitar a banda utilizada pelo squid em 229376

acl localhost src 127.0.0.1/255.255.255.255

acl rede_interna src 192.168.0.0/24

delay_pools 1

delay_class 1 2

delay_parameters 1 229376/229376 32768/32768

delay_access 1 allow rede_interna

http_access allow localhost

http_access allow rede_interna

http_access deny all

Eu reservei 229376 bytes por segundo para o Squid

Eu reservei 32768 bytes por segundo para outros protocolos

87% para o squid

13% para outros protocolos

A acl rede_interna está agora condicionada o três novas regras, que aplicam o uso do limite de banda. O acesso continua sendo permitido, mas agora dentro das condições especificadas na linha “delay_parameters 1 229376/229376 32768/32768”, onde vão os valores com a banda total disponível para o squid, e a banda disponível para cada usuário.

Observe que a regra só é aplicada a rede_interna atuando somente nas estações e não ao localhost (127.0.0.1) podendo assim fazer download na velocidade máxima permitida pelo link, quando acessado pelo servidor.

É possível também criar regras de exceção para determinados endereços, essas acl's não passarão pelo filtro de banda. Neste caso criamo uma acl com os endereços desejados.

acl localhost src 127.0.0.1/255.255.255.255

acl diretoria src 192.168.0.2

http_access allow diretoria

acl rede_interna src 192.168.0.0/24

delay_pools 1

delay_class 1 2

delay_parameters 1 229376/229376 32768/32768

delay_access 1 allow rede_interna

http_access allow localhost

http_access allow rede_interna

http_access deny all

Essa regras vale para as demais configurações vista acima, basta colocar a regras antes de qualquer acl,

acl diretoria src 192.168.0.2

http_access allow diretoria

Finalizando

# squid -k parse

# squid -k reconfigure

Obs: Evite usar “#/etc/init.d/squid restart” em ambientes em produção, pois ele força um reinício completo do squid, onde p proxy precisa finalizar todas as conexões abertas, finalizar todos os processos de desativar o cache, para só então ler a configuração e recarregar todos os componentes novamente. Isso faz com que o proxy fique um tempo sem responder as conexões, fazendo qom que o acesso fique fora do ar.

Obrigado pela atenção de todos, sugestões serão sempre bem vindas.

Até o próximo material

Squid - parte 05

2009-02-09T07:03:00.000-08:00

Auditando os acessos com o SARG

O SARG Squid Analysis Report Generator é uma ferramenta desenvolvida pelo brasileiro Pedro Lineu Orso, cujo objetivo é analisar o arquivo /var/squid/log/access.log e gerar um relatório de acesso baseado no conteúdo acessado pelos usuários.

Sua instalação é bem simples, bastando apenas, no Debian, executar um aptitude:

# aptitude install sarg

Vamos observar seu arquivo de configuração. Fique a vontade e leia alguns comentários para entende as funções do SARG.

# vi /etc/squid/sarg.conf

Configure o arquivo como de acordo com sua preferencia. Aqui podemos editar as fontes, nome do arquivo gerado.

Exemplo de algumas sessoes do arquivo

# linguage exibida

language Portuguese

# titulo do relatório

title "Squid User Access Reports"

# nome do arquivo e saida

output_dir /var/www/squid

Saia do arquivo e execute o sarg:

# sarg

http://192.168.0.3/squid/

O sarg pode ser configurado no crontab para ser executado varias vezes ao dias, analisando assim o log de acessos do Squid.

Squid - parte 4

2009-02-09T06:39:00.000-08:00

Squid como proxy transparente

Uma garantia de que os usuários realmente irão utilizar o proxy é tornando o mesmo de forma transparente, economizando assim o trabalho de configurar manualmente cada estação. Mesmo que alguem tente desativar seu proxy no navegardor ele continua sendo usado. Lembre-se que para usar o proxy transparente é necessario que voce já esteje compartilhando a Internet via NAT, o proxy interceptará todo trafego que passar pela porta 80, obrigando assim passar por suas regras de controle de acesso.

Na versão utilizada neste material a configuração no squid.conf é simples basta efetuar a alteração a linha listada abaixo.

http_port 192.168.0.3:3218

alterar para

http_port 192.168.0.3:3218 transparent

ou seja, precisamos apenas adicionar o “transparent” para que o squid passe a entender as requisições redirecionadas pelo firewall.

As seguintes linhas deveram ser inseriras em seu firewall

$vIptables -A INPUT -p tcp -i $vi_Rede --dport 3128 -j ACCEPT

$vIptables -t nat -A PREROUTING -p tcp -i $vi_Rede --dport 80 -j REDIRECT --to-port 3128

$vIptables -t nat -A PREROUTING -p tcp -i $vi_Rede --dport 8080 -j REDIRECT --to-port 3128

Onde:

1 linha - libera a porta 3128 no firewall

2 linha - direciona o trafego que chega da interface $vi_Rede na porta 80 para a porta 3128

3 linha - direciona o trafego que chega da interface $vi_Rede na porta 8080 para a porta 3128

$vIptables - variável que indica o caminho do iptables /sbin/iptables

$vi_Rede - variável que indica sua interface de rede

O restante das regras será abordado no material sobre iptables

Em caso de se usar versões anteriores à 2.6 é necessário adicionar algumas outras configurações no squid.cond, são elas:

httpd_accel_host virtual

httpd_accel_port 80

httpd_with_proxy on

httpd_accel_uses_host_header on

Em resumo, ao usar proxy transparente você vai ter a conexão compartilhada via NAT no servidor e configurará os clientes para acessar através dela, configurando assim nos clientes o servidor como gateway padrão da rede.

Uma observação muito importante é que essa configuração de proxy transparente não funciona com o sistema de autenticação incluso no squid.

Em um próximo material será abordado uma solução para que não seja necessário configuração em clientes e que se possa usufruir do sistema de autenticação.

Squid - parte 3

2009-02-09T05:27:00.001-08:00

Criando acl's com bloqueio por horário

# vi squid.conf

acl extensoes_bloqueadas url_regex -i "/etc/squid/acl/extensoes_bloqueadas.acl"

acl horario time MTWHF 12:00-13:00

acl url_horario dstdomain "/etc/squid/acl/url_horario.acl"

http_access allow rede horario url_horario

http_access deny !rede

# squid -k parse

# squid -k reconfigure

Com exceção das acl's de trabalho todos outros acesso serão necessários sua autenticação, caso o usuário não se autentique uma mensagem de ACESSO NEGADO será enviada ao navegador.

Squid - parte 2

2009-02-09T05:01:00.000-08:00

Filtrando acessos com Squid

Uma das obrigações de um Administrador de Sistemas em alguns ambientes é controlar o que deve ou não deve ser acessível na internet a partir da rede interna.

Criando as acl's (access control list's)

As acl's são listas de controle de acesso onde pode facilitar muito a administração do arquivo de configuração, por exemplo, imagina o administrador tendo que escrever 1000 palavras que serão bloqueadas, url's que surgem a cada dia, liberar novas url's que por ventura venham ser bloqueadas, conhecidas como falso positivo. As acl's neste caso facilitam muito na administração, pois basta criar uma arquivo, inserir o que se deseja bloquear ou liberar e indicar o mesmo no arquivo de configuração.

# mkdir acl

# cd acl

# touch palavras_bloqueadas.acl

# touch extensoes_bloqueadas.acl

# touch url_bloqueadas.acl

# touch url_liberadas.acl

# touch url_trabalho.acl

# touch url_horario.acl

Com um editor de texto de sua escolha insira as seguintes linhas

# vi squid.conf

acl rede src 192.168.0.0/24

acl url_bloqueadas dstdomain "/etc/squid/acl/url_bloqueadas.acl"

acl url_liberadas dstdomain "/etc/squid/acl/url_liberadas.acl"

acl url_trabalho dstdomain "/etc/squid/acl/url_trabalho.acl"

acl palavras_bloqueadas dstdom_regex -i "/etc/squid/acl/palavras_bloqueadas.acl"

acl extensoes_bloqueadas url_regex -i "/etc/squid/acl/extensoes_bloqueadas.acl"

dstdomain e url_regex - Quanto ao dstdomain e url_regex, o dstdomain vc bloqueia um domínio (.orkut.com), e o url_regex você bloqueia por pedaços da URL. Por exemplo se vc quer bloquear o dominio todo do terra, você pode usar o dstdomain colocando ".terra.com.br". Mas se vc quiser bloquear todos os portais que tenham CHAT, você bloqueia no URL_REGEX a palavra chat, aí ele bloqueia o chat do Terra, do Uol, da Globo, etc.. (Terra Chat, Bate-papo UOL, etc.)
Em suma, dstdomain bloqueia DOMINIOS, url_regex bloqueia PALAVRAS contidas na url toda.

dstdom_regex - O uso desta regra é um pouco mais problemático, pois bloqueará todas páginas que contenham qualquer uma das palavras listadas na URL. Esta opção sempre levará a alguns falsos positivos e por isso deve ser usada com mais cuidado.

Uma vantagem é que ela permite bloquear facilmente páginas dinâmicas, onde a palavra é passada como parâmetro da URL. Um exemplo é o Orkut, onde, depois da transferência para o Google, os domínios principais passaram a encaminhar para URLs dinâmicas dentro do domínio do Google, como em:

https://www.google.com/accounts/ServiceLogin?service=orkut&continue=http%3A%2F%2Fwww.orkut.com%2FRedirLogin.aspx%3Fmsg%3D0%26page%3Dhttp%253A%252F%252Fwww.orkut.com%252FHome.aspx&hl=pt-BR&rm=false&passive=true

Você não poderia simplesmente bloquear o domínio "google.com" usando uma regra url_regex, mas poderia muito bem usar o dstdom_regex para bloquear a palavra "orkut" e assim bloquear o acesso ao site sem bloquear o acesso a outros serviços do Google.

-i - Indica que não será respeitado o case-sensitive.

http_access deny !rede

http_access deny rede url_bloqueadas

http_access deny rede palavras_bloqueadas

http_access deny rede extensoes_bloqueadas

http_access allow rede url_trabalho

# libera tudo pra rede exceto as url_bloqueadas e palavras_bloqueadas

http_access allow rede !url_bloqueadas !palavras_bloqueadas

http_access allow rede url_liberadas

http_access allow rede

http_access deny all

icp_access allow all

Salve e saia do arquivo de configuração

É necessário preencher as acl's antes de reiniciar o squid, use um editor de texto de sua preferencia e preencha cada arquivo antes criado.

# echo “.jpeg$” > extensoes_bloqueadas.acl

# echo “.microsoft.com” > url_bloqueadas.acl

# echo “.orkut.com” > url_horario.acl

# echo “.bb.com.br” > url_trabalho.acl

# echo “.caixa.com.br” >> url_trabalho.acl

# echo “sexo” > palavras_bloqueadas.acl

# echo “sexy” >> palavras_bloqueadas.acl

A mensagem abaixo é mostrada quando é encontrado uma acl vazia.

# squid -k parse

2009/02/05 00:19:39| aclParseAclLine: WARNING: empty ACL: acl url_liberadas dstdomain "/etc/squid/acl/url_liberadas.acl"

2009/02/05 00:19:39| ACL name 'autenticados' not defined!

FATAL: Bungled squid.conf line 48: http_access allow autenticados

Squid Cache (Version 2.6.STABLE18): Terminated abnormally.

Preencha a acl e reconfigure o squid.

# squid -k parse

# squid -k reconfigure

Squid - parte 1

2009-02-09T04:46:00.000-08:00

Neste meterial será mostrado a instalação e configuração básica do squid, bloqueio de conteúdo utilizando acl's, proxy transparente, autenticação, auditoria como sarg e controle de banda. A versão utilizada será a 2.6.STABLE18, todos os testes foram feitos no Ubuntu 8.04 kernel 2.6.24-22

O Squid é um servidor proxy que suporta HTTP, HTTPS, FTP e outros. Ele reduz a utilização da conexão e melhora os tempos de resposta fazendo cache de requisições freqüentes de páginas web numa rede de computadores.

Verificando se o pacote está instalado.

# dpkg -l | squid

O programa 'squid' não está instalado atualmente. Você pode instalá-lo digitando: apt-get install squid

Instalando o Squid

# apt-get install squid

# squid -v

Squid Cache: Version 2.6.STABLE18

Após confirmar a instalação do squid, verifique o conteúdo dos diretórios mencionados.

# ls /var/spool/squid

# ls /var/log/squid

# ls /etc/squid

O arquivo de configuração se encontra no diretório /etc/squid

# cd /etc/squid

Antes de fazer qualquer alteração faça uma copia do arquivo original

# cp squid.conf squid.conf.original

A configuração padrão do squid não permite nenhum tipo de navegação, por medidas de segurança. A primeira coisa que devemos fazer é especificar qual rede o squid deve ouvir, e também devemos especificar uma ACL do tipo origem que case com o nosso endereço IP. Vamos fazer isso.

Para que o squid ouça apenas uma rede, troque o valor do parâmetro "http_port 3128" para:

http_port 192.168.0.3:3128

Outra configuração importante é o parâmetro visible_hostname. Este parâmetro diz qual será o hostname que o squid irá utilizar para resolver seu endereço local e também é o endereço que será apresentado nas páginas de informação

visible_hostname proxy.seunome.com.br

Seu arquivo é muito extenso, após a instalação removi todos os comentários, deixando apenas a configuração padrão, facilitando assim a adaptação a nossa realidade.

# vi squid.conf

# WELCOME TO SQUID 2.6.STABLE18

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 to_localhost dst 127.0.0.0/8

acl SSL_ports port 443 # https

acl SSL_ports port 563 # snews

acl SSL_ports port 873 # rsync

acl Safe_ports port 80 # http

acl Safe_ports port 21 # ftp

acl Safe_ports port 443 # https

acl Safe_ports port 70 # gopher

acl Safe_ports port 210 # wais

acl Safe_ports port 1025-65535 # unregistered ports

acl Safe_ports port 280 # http-mgmt

acl Safe_ports port 488 # gss-http

acl Safe_ports port 591 # filemaker

acl Safe_ports port 777 # multiling http

acl Safe_ports port 631 # cups

acl Safe_ports port 873 # rsync

acl Safe_ports port 901 # SWAT

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

# INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS

http_access allow rede

http_access deny all

icp_access allow all

hierarchy_stoplist cgi-bin ?

access_log /var/log/squid/access.log squid

acl QUERY urlpath_regex cgi-bin \?

cache deny QUERY

#Suggested default:

refresh_pattern ^ftp: 1440 20% 10080

refresh_pattern ^gopher: 1440 0% 1440

refresh_pattern . 0 20% 4320

acl apache rep_header Server ^Apache

broken_vary_encoding allow apache

extension_methods REPORT MERGE MKACTIVITY CHECKOUT

hosts_file /etc/hosts

Localize a sessão ( # INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS ) e insira as linhas abaixo.

acl rede src 192.168.0.0/24

http_access allow rede

http_access deny all

icp_access allow all

http_port 192.168.0.3:3128

visible_hostname ubuntu

hierarchy_stoplist cgi-bin ?

# Ajuste do cache em disco: Iremos especificar 512MB de cache, com 128

# diretórios e 256 subdiretórios:

cache_dir ufs /var/spool/squid 512 128 256

# Definindo o cache que será armazenado em memória:

cache_mem 16 MB

# Define o tamanho máximo de um arquivo que será armazenado no cache na memória # RAM, se passar disso aí (128 KB) vai parar no disco rígido.

maximum_object_size_in_memory 128 KB

# Define o tamanho máximo de um arquivo armazenado.

maximum_object_size 256 MB

# Define o tamanho mínimo do arquivo em cache.

minimum_object_size 0 KB

# Essas diretivas definem em porcentagem que se o limite de 85% do cache for

# utilizado os arquivos antigos começam descartados até chegar a 80%.

cache_swap_low 80

Agora, iremos parar o squid, verificar a sintaxe do arquivo de configuração,gerar o cache e então reiniciaremos o squid.

# invoke-rc.d squid stop

# squid -k parse

# squid -z

# invoke-rc.d squid start

Toda vez que você mudar as ACL's você deve executar os comandos:

# squid -k parse

# squid -k reconfigure

Até seu squid já estará funcionando, porém sem nenhum tipo de filtro.

SSH Security Shell

2008-11-16T16:11:00.000-08:00

SSH - Secure SHell

Secure Shell ou  SSH é um conjunto de padrões e o protocolo que permite estabelecer um canal seguro entre dois computadores. O SSH utiliza o sistema de criptografia de chave pública para autenticar um computador remoto, podendo utilizar esse sistema de chaves também para autenticar usuários. A idéia do SSH é prover confidencialidade e integridade dos dados trocados entre dois computadores usando criptografia. Com SSH posso executar comandos em uma máquina remota, conexões X11 (com interface gráfica), além de transferência de arquivos.
O SSH é uma alternativa ao TELNET e FTP, uma vez que eles não utilizam criptografia. Ao configurar o SSH em uma estação estamos falando tanto de servidor como de  cliente, pois outras clientes também podem se conectar á estação que assim será chamada se será chamada de servidor. E quando falo se conectar na minha máquina... estou falando em ter um shell como se fosse a máquina mesmo, tendo o total poder, levando em consideração com que usuário eu fiz a conexão! Ou seja, posso fazer tudo (em modo texto) acessando uma máquina remotamente... Mas sempre lembrando que eu preciso ter um usuário e permissão!!!
Existe uma diferença em minha máquina ser um servidor ssh, e ser cliente.

Ser  Servidor SSH - Possibilito outras máquinas se conectarem na minha.
Ser  Cliente SSH - Posso apenas me conectar em uma máquina que tenha Servidor SSH.

Antes de vermos a configuração do SSH, temos que entender como acontece uma conexão ssh. Entender como isso funciona ajuda muito na hora em que você for configurar um Firewall.

Tenho duas máquinas na rede:
ServerSSH <---------------------> ClientSSH

Ou seja, a minha máquina ClientSSH vai acessar o servidor, que nada mais é que qualquer outra máquina com o ssh instalado e configurado.

Agora, como ocorre essa conexão a nível de TCP/IP...

Para o cliente estabelecer uma conexão ele precisa saber a porta que o serviço está usando. Cada serviço no Linux usa uma porta específica. Por padrão, o SSH usa a porta 22.

Entendendo como funciona a conexão ssh...

Quando o cliente for estabelecer uma conexão SSH com o servidor para dar certo ele tem que bater na porta correta, ou seja, ele deverá bater na porta 22 para conversar.

ServerSSH <--(Porta 22)------ ClientSSH 
O cliente tem que pedir uma conexão na Porta 22 do servidor, mas por qual porta o cliente sai? Não vai ser pela porta 22, pois a essa é para se conectarem nele por ssh. Podemos imaginar que seria a nossa porta dos fundos. Então, o cliente sai por qualquer porta que não é usada para um serviço específico. As portas que não são usadas para nenhum uso específico chamamos de portas altas. Elas vão de 1024 até 65535. Essa portas ficam disponíveis justamente para isso. E portas altas são tanto para entrada quando para saída  Voltando ao exemplo...

O cliente pede a conexão para o servidor:  
ServerSSH <--(Porta 22)----------(Portas Altas)--- ClientSSH 

Agora se o servidor realmente está com essa porta disponível, ele tem que responder para o cliente. Para responder, ele vai ter que sair da máquina dele e se conectar ao no cliente falando que está disponível.  Ficando assim:
ServerSSH <--(Porta 22)----------(Portas Altas)--- ClientSSH  
ServerSSH --(Porta 22)----------(Portas Altas)---> ClientSSH

Resumindo:
O cliente vai pedir uma conexão da porta 22 e o servidor vai responder em qualquer porta alta que estiver disponível criando ai um túnel de conexão onde estarão sendo trafegadas as informações. Depois disso, o cliente precisará se autenticar, caso contrário o servidor irá rejeitar a conexão. Ou seja, você precisará ter um usuário e senha no servidor.
Sabendo como ocorre o processo de conexão, vamos então a configuração desse serviço.

Instalando o SSH:
# aptitude install ssh

Daí, já posso entrar no diretório onde ficam os arquivos de configuração.
#cd /etc/ssh/

Lá terei 2 arquivos principais:
sshd_config -  Arquivo de configuração do servidor
ssh_config -  Arquivo de configuraçõ do cliente

Vamos editar o arquivo de configuração do servidor:
# vi /etc/ssh/sshd_config

Comentarei as principais linhas

Lembrando que a maior parte das linhas dizem respeito aos arquivos para a criptografia do serviço e não é aconselhável mudar!

Pacote servidor SSH:
Servidor: # aptitude install openssh-server
Cliente:  # aptitude install openssh-client

A primeira linha:

Port 2245
Porta padrão usada pelo servidor sshd. Posso mudar a porta, caso queira fugir do padrão, mas o cliente deverá saber disso para poder especificar em que porta bater. No caso do SSH é extremamente recomendado trocar essa porta já que provavelmente você (ADM) que será o cliente para administrar a máquina, com isso esse serviço não fica aberto para qualquer um, apenas para os que realmente sabem a porta que você setou! Claro que isso não significa que mudando a porta você está totalmente seguro, mas é interessante que mude. Se for mudar a porta, escolha uma porta alta, como, por exemplo, 2245

Próxima linha:

Protocol 2,1
São Protocolos aceitos pelo servidor.Devemos sempre apenas usar o Protocolo 2. O protocolo 1 do ssh já está totalmente bugado. Quando falo bugado estou me referindo a exploits que já me dão acesso root, explorando essas brechas no serviço! Nas últimas versões do SSH já nem vem mais o protocolo 1 setado, mas se você for da manutenção em um servidor mais antigo é importante que saiba desse detalhe. Protocolo nesse caso é apenas um conjunto de ações que o servidor realiza. Ou seja, protocolos determinam como o SSH vai se comportar. Do jeito que está a minha linha, estou aceitando os 2, mas dando preferência para o 2.
Protocol 2,1
Não devemos deixar assim. Deixe apenas o número 2,
Protocol 2

Próxima linha:

LoginGraceTime 30
A função dessa linha é determinar o tempo limite em segundos permitido para fazer login. Nesse caso então 30 segundos são suficientes para você digitar login e senha. Quanto mais tempo for colocado aqui, mas inseguro a autenticação pode ficar, pois daí alguém pode ficar tentando autenticar “chutando” senhas.

Próxima linha:

PermitRootLogin yes
Permite (yes) ou não (no) o login do usuário root. E essa com certeza temos que sempre deixar no.
PermitRootLogin no

A idéia é sempre fazer a conexão sendo um usuário mortal (limitado) e depois virar root quando já estiver lá dentro com o comando su. Sendo assim, o invasor terá que saber além da senha do root, uma senha de usuário normal também. Como medida de segurança nunca deixem que o root tenha acesso. Por padrão, o SSH permite que qualquer usuário cadastrado no sistema se logue remotamente, mas você pode criar uma lista de quem vai ou não acessar o sistema remotamente.

Próxima linha:

AllowUsers falexreis alexandre linus
Nesse caso, apenas os usuários falexreis, alexandre e linus conseguiriam fazer acesso remoto.

O contrário é: DenyUsers
Exemplo:
DenyUsers debian

Atenção: O usuário estar na linha DenyUsers não significa que ele não poderá o usar o sistema. Ele só não poderá fazer acesso remoto. Localmente ele continuará usando o sistema. Ou você usa a linha AllowUsers ou DenyUsers. Não use as duas juntas, pois não é necessário, isto é, quem não estiver na AllowUsers não pode acessar remotamente.

PermitEmptyPasswords no
Essa linha permite ou não que o SSH aceite senhas vazias. O padrão é no. Deixe como no.

Próxima linha:

ListenAddress 0.0.0.0
Se você quiser que o SSH só fique disponível para rede local, substitua o 0.0.0.0 pelo IP que o servidor tiver utilizando, por exemplo:

ListenAddress 192.168.0.1

0.0.0.0 quer dizer, sem restrição de IP, ou seja, que não importa o endereço da interface.

Essa opção permite limitar o SSH a uma única placa de rede. É usada quando o computador tem duas ou mais placas de rede.

Se você quer exibir uma mensagem antes do prompt de login, a mensagem é especificada através dessa linha. Essa opção aponta para o arquivo que conterá a mensagem. Geralmente essa linha vem comentada, portanto é necessário descomentá-la caso você queira usar.

Próxima linha:

X11Forwarding yes
Essa linha define se o servidor permitirá que os clientes executem aplicativos gráficos remotamente.
Se o servidor será acessado via internet ou se possui um link lento, você pode deixar esta opção como no para economizar banda

Leitura sugerida:
# man sshd_config

Pronto! Podemos salvar o arquivo.

Para levantar o serviço (Debian):
# /etc/init.d/ssh start

Red Hat
# service sshd start

Agora meu serviço está no ar, mas tenho que garantir isso.
Então, executo alguns passos que chamamos de "checklist do administrador".

O primeiro passo a fazer depois que executei o serviço é ver se o processo está rodando:

#ps aux
ou
#pgrep ssh
ou
#ps aux | grep ssh

Se o processo está rodando significa que o serviço subiu.

Depois tenho que ver se a porta do ssh está disponível, ou seja, se o meu cliente vai poder selçicitar uma conexão.

Executo esse comando para isso:

# netstat -anp | grep 22
tcp        0      0 0.0.0.0:22              0.0.0.0:*               OUÇA       2248/sshd

Onde:
a é para todas (all);
n é para ser numérico, ou seja, não vai resolver nome.
p para verificar o processo responsável (PID).

Lembrando que se você trocou a porta padrão, terá que mudar o comando também!

Se minha porta estiver em estado de LISTEN ou OUÇA  significa que ela está ouvindo, ou seja, está disponível.

Depois façam o teste, se você derrubar o servidor ssh e der o comando novamente, verá que ela não vai aparecer disponível.

Uma outra forma para ver se o cliente vai enxergar a porta aberta é com o comando:

#nmap localhost -p 22
Starting nmap 3.75 ( http://www.insecure.org/nmap/ ) at 2005-06-20 19:40 BRT
Interesting ports on localhost.localdomain (127.0.0.1):
PORT   STATE SERVICE
22/tcp open  ssh

Nmap run completed -- 1 IP address (1 host up) scanned in 0.136 seconds


Você pode utilizar o Windows através um cliente SSH feito para Windows chamado Putty para acessar o Linux.

Esse comando mostra se a porta que está aberta na minha máquina.
Em algumas distros (Debian é uma) esse comando não vem instalado.
Portanto:
# aptitude install nmap

Vamos ver agora como utilizar o SSH como cliente, acesso e transferência de arquivos.

O SSH possui diversas formas de utilização.

Para fazer um acesso remoto:
# ssh @

Exemplo:
# ssh falexreis@200.6.243.31 

Se a porta do servidor não é a padrão (22), você precisa especificar a porta:
# ssh falexreis@200.6.243.31 -p 2245
Coloco a senha e já estou com o shell do servidor!

 Como dito anteriormente, o SSH usa um sistema baseado em chaves assimétricas para verificar a identidade do servidor. O servidor tem uma chave pública, que é enviada ao cliente na primeira conexão. As identificações de todos os servidores conhecidos ficam armazenadas no arquivo .ssh/known_hosts dentro do diretório pessoal do cliente. Sempre após a primeira conexão em que você se conecta, é necessário verificar se a chave pública se encaixa com a chave privada. Isso é útil para prevenir um ataque chamado de "man-in-the-middle", no qual alguém substitui o servidor por outra máquina, usando o mesmo endereço IP. O falso servidor pode ser configurado para pegar sua senha. Mas por sorte, o SSH percebe que a identificação do servidor mudou e lhe avisa do problema.

 Você só conseguirá acessar o servidor novamente sem a mensagem de erro se a linha no arquivo known_hosts do fingerprint do servidor for removida, as vezes, o mais prático é remover o known_hosts. Na próxima conexão com o  servidor esse arquivo é criado novamente.

 Para copiar arquivos de uma máquina para outra, deve-se seguir a mesma lógica do comando cp, que funciona da seguinte forma:
# cp  

Só que o comando de cópia no SSH chama-se scp:
# scp  

A diferença agora é que a origem e/ou destino podem ser remotos.

Exemplos:
Da máquina local para a máquina remota (upload):
# scp  @

Da máquina remota para a máquina local(download):
# scp @: 
  
 Vamos supor que eu máquina cliente quero pegar um arquivo que está lá no servidor dentro do diretório /tmp por exemplo. Primeiro, lógico, tenho que ter acesso a esse diretório pelo usuário que vou me autenticar. Estou considerando o /tmp por ser público

Então faço assim:
  #scp falexreis@200.6.243.31:/tmp/arquivo.txt /tmp

 Ou seja, o usuário falexreis, vai logar no servidor (200.6.243.31) e dentro do tmp (:/tmp), vai copiar o arquivo arquivo.txt para o /tmp minha máquina.
Agora vamos fazer assim:
Eu usuário falexreis quer pegar todos os arquivos que estão no home (tem acesso a isso)
#scp -r 200.6.243.31:/home/falexreis/ /tmp
Ou seja, o -r aqui está falando que deverá ser recursivo, vai copiar o diretório e tudo que tem dentro dele! Depois do IP sempre tenho que colocar : e o caminho completo do arquivo no servidor.

Outro exemplo:

Mandando um arquivo da minha máquina para o servidor (upload):

$ scp -P 2245 artigos.bz2 200.6.243.31:/home/falexreis/artigos

Nesse caso a porta do servidor não é a padrão, então basta autenticar para que o arquivo seja enviado.
  
Aprofundando o assunto sobre chaves de criptografia assimétrica.

Vantagens:
Serve para aumentar o nível de segurança;
Facilita a execução de scripts remotamente;
  
Consiste em 2 arquivos:
- Chave privada (id_rsa);
- Chave pública (id_rsa.pub)

 A chave privada é absolutamente sua, e, por segurança, ninguém deve ter acesso à ela. Então, o cliente só vai conseguir acessar o servidor, se sua chave se encaixar com a chave do servidor. A chave publica fica no servidor. A chave privada fica na sua máquina (ou melhor fica na máquina que você usa para acessar o servidor ssh)

Isso aumenta a segurança porque:
- Você precisa ter a chave privada para acessar o servidor;
- Além da chave, você precisa saber passphrase.

Vamos criar a chave (isso na máquina cliente):

$ ssh-keygen -t rsa

Vai ser pedido a passphrase, aí você escolhe uma.
As chaves vão ficar em:

$ cd ~/.ssh

Isso vai gerar os arquivos id_rsa e id_rsa.pub dentro do seu diretório home

A chave pública deve ser mandada para a máquina remota (servidor):

$ scp ~/.ssh/id_rsa.pub seu_login@ip_do_servidor:.ssh/authorized_keys

Se mudar a porta coloca-se  -p porta

Ou você pode fazer isso (é bem mais prático):

$ ssh-copy-id login@servidor

 O ssh-copy-id copia o conteúdo do arquivo .ssh/id_rsa.pub, dentro do seu diretório home para dentro do arquivo .ssh/authorized_keys dentro do diretório home do servidor remoto. Esse passo pode ser feito manualmente em caso de problemas, por isso passei os dois modos.

Aí depois é só acessar o servidor:
$ ssh seu_login@ip_do_servidor

Juiz de Fora 16/11/2008

Por hoje é só...

Esse é meu primeiro Artigo aqui, em breve postarei mais.

Fonte: Curso Linux System Administrator - 4Linux                         