[ anterior ] [ Conteúdo ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ 13 ] [ 14 ] [ 15 ] [ 16 ] [ 17 ] [ 18 ] [ 19 ] [ 20 ] [ 21 ] [ próximo ]

Guia Foca GNU/Linux
Capítulo 15 - Servidor ssh

Este capítulo documenta a instalação, configuração e personalização do servidor de shell seguro sshd, além de explicar as vantagens da utilização dos serviços criptográficos. A utilização do programa cliente ssh também é explicada, além de utilitários usados para geração de chaves pública/privada para o ssh (autenticação RSA/DAS - o que é, vantagens), cópia de arquivos e métodos de autenticação usando o método de chave pública/privada RSA.

Ambas as versões 1 e 2 do ssh são documentadas neste capítulo. Opções específicas do protocolo 1 ou 2 do ssh serão destacadas.

15.1 Introdução

O serviço de ssh permite fazer o acesso remoto ao console de sua máquina, em outras palavras, você poderá acessar sua máquina como se estivesse conectado localmente ao seu console (substituindo o rlogin e rsh). A principal diferença com relação ao serviço telnet padrão, rlogin e rsh é que toda a comunicação entre cliente/servidor é feita de forma encriptada usando chaves públicas/privadas RSA para criptografia garantindo uma transferência segura de dados.

A velocidade do console remoto conectado via Internet é excelente (melhor que a obtida pelo telnet e serviços r*) dando a impressão de uma conexão em tempo real (mesmo em links discados de 9.600 KB/s), a compactação dos dados também pode ser ativada para elevar ainda mais a velocidade entre cliente-servidor ssh. Além do serviço de acesso remoto, o scp possibilita a transferência/recepção segura de arquivos (substituindo o rcp).

Em conexões sem criptografia (rsh, rlogin) os dados trafegam de forma desprotegida e caso exista algum sniffer instalado em sua rota com a máquina destino, todo o que fizer poderá ser capturado (incluindo senhas).

15.1.1 Versão

É assumido que esteja usando a versão 2.0 do ssh. As explicações contidas aqui podem funcionar para versões posteriores, mas é recomendável que leia a documentação sobre modificações no programa (changelog) em busca de mudanças que alterem o sentido das explicações fornecidas aqui.

15.1.2 História

O openSSH (explicado neste capítulo) é baseado na última versão livre do implementação de Tatu Ylonen com todos os algoritmos patenteados (para bibliotecas externas) removidos, todos as falhas de segurança corrigidas, novas características e muitas outras melhorias. O openSSH foi criado por Aaron Campbell, Bob Beck, Markus Friedl, Niels Provos, Theo de Raadt e Dug Song.

15.1.3 Contribuindo

A Home page principal é http://www.unixuser.org/~haruyama/security/openssh/index.html. Falhas, correções e sugestões podem ser enviadas para a lista de discussão openssh-unix-dev@mindrot.org (aberta a postagens de usuários não inscritos).

15.1.4 Características

Abaixo as principais características do serviço ssh (Openssh).

15.1.5 Ficha técnica

Pacote: ssh

Utilitários:

Arquivos de configuração:

15.1.6 Requerimentos de Hardware

É recomendado no mínimo 6MB de memória RAM para a execução do serviço ssh mais o kernel do Linux. Este limite deve ser redimensionado para servidores de acesso dedicado, uma quantidade de 64MB deve ser confortável para centenas de usuários conectados simultaneamente (o que raramente acontece).

Veja também Restrições de acesso, recursos e serviços, Capítulo 19 para configuração de restrições usando PAM. O ssh que acompanha a distribuição Debian vem com o suporte a tcp wrappers compilado por padrão.

15.1.7 Arquivos de log criados pelo servidor ssh

Detalhes sobre a execução do servidor sshd (como inicio, autenticação e término) são enviadas ao syslog do sistema. A prioridade e nível são definidos no arquivo de configuração /etc/ssh/sshd_config (veja Exemplo de sshd_config com explicações das diretivas, Seção 15.3.8).

15.1.8 Instalação do servidor openSSH

apt-get install ssh.

Por padrão o servidor sshd é instalado como daemon, também é possível executa-lo via inetd mas isto não é aconselhável porque o servidor gera uma chave aleatória de seção toda vez que é iniciado, isto podendo levar vários segundos (quando é usada a versão 1 do protocolo ssh, veja Diferenças nas versões do protocolo, Seção 15.3.7).

15.1.9 Iniciando o servidor/reiniciando/recarregando a configuração

O arquivo que controla o funcionamento do daemon do ssh é controlado pelo arquivo /etc/init.d/ssh.

A execução do ssh através de inetd é automática quando é feita uma requisição para a porta 22.

15.1.10 Opções de linha de comando

Opções de linha de comando do servidor sshd:

A maioria das opções são realmente úteis para modificar o comportamento do servidor ssh sem mexer em seu arquivo de configuração (para fins de testes) ou para executar um servidor ssh pessoal, que deverá ter arquivos de configuração específicos.

15.2 Usando aplicativos clientes

Esta seção explicará o uso dos utilitários ssh, scp e sftp.

15.2.1 ssh

Esta é a ferramenta usada para seções de console remotos. O arquivo de configuração de usuários é ~/.ssh/config e o arquivo global /etc/ssh/ssh_config. Para conectar a um servidor ssh remoto: 

     ssh usuario@ip/nome_do_servidor_ssh

Caso o nome do usuário seja omitido, seu login atual do sistema será usado. O uso da opção -C é recomendado para ativar o modo de compactação dos dados (útil em conexões lentas). A opção -l usuário pode ser usada para alterar a identificação de usuário (quando não é usada, o login local é usado como nome de usuário remoto). Uma porta alternativa pode ser especificada usando a opção -p porta (a 22 é usada por padrão).

Na primeira conexão, a chave pública do servidor remoto será gravada em ~/.ssh/know_hosts ou ~/.ssh/know_hosts2 (dependendo da versão do servidor ssh remoto, veja Diferenças nas versões do protocolo, Seção 15.3.7), e verificada a cada conexão como checagem de segurança para se certificar que o servidor não foi alvo de qualquer ataque ou modificação não autorizada das chaves. Por padrão, o cliente utilizará o protocolo ssh versão 1, a opção -2 permite usar o protocolo versão 2.

Variáveis de ambiente personalizadas para o ssh poderão ser definidas no arquivo ~/.ssh/environment. Comandos que serão executados somente na conexão ssh em ~/.ssh/rc e /etc/ssh/sshrc caso contrário será executado o xauth por padrão.

OBS: Para utilizar autenticação Rhosts/Rhosts+RSA (arquivos ~/.rhosts/~/.shosts) o programa ssh deverá ter permissões SUID root e conectará usando portas baixas (menores que 1024). 

     Exemplos:
     # Conecta-se ao servidor remoto usando o login do usuário atual
     ssh ftp.sshserver.org
     
     # Conecta-se ao servidor remoto usando o login john (via ssh versão 2)
     ssh -2 ftp.sshserver.org -l john
     
     # Conecta-se ao servidor remoto usando compactação e o login john
     ssh ftp.sshserver.org -C -l john
     
     # Semelhante ao exemplo acima, usando o formato "login@ip"
     ssh john@ftp.sshserver.org -C
     
     # Conecta-se ao servidor remoto usando compactação, o login john, 
     # ativa o redirecionamento do agente de autenticação (-A) e redirecionamento 
     # de conexões X11 (-X). Veja a próxima seção para entender como o 
     # suporte a redirecionamento de conexões do X funciona. 
     ssh ftp.sshserver.org -C -A -X -l john

15.2.1.1 Redirecionamento de conexões do X

O redirecionamento de conexões do X Window poderá ser habilitado em ~/.ssh/config ou /etc/ssh/ssh_config ou usando as opções -A -X na linha de comando do ssh (as opções -a e -x desativam as opções acima respectivamente). Uma variável $DISPLAY é criada automaticamente para fazer o redirecionamento ao servidor X local.

Ao executar um aplicativo remoto, a conexão é redirecionada a um DISPLAY proxy criado pelo ssh (a partir de :10, por padrão) que faz a conexão com o display real do X (:0), ou seja, ele pulará os métodos de autenticação xhost e cookies. Por medidas de segurança é recomendável habilitar o redirecionamento individualmente somente se você confia no administrador do sistema remoto. 

     # Exemplo de configuração do ssh_config
     
     # Permite Redirecionamento de conexões para o próprio computador (nomes de 
     # máquinas podem ser especificadas). 
     Host 127.0.0.1
         ForwardAgent yes
         ForwardX11 yes
     
     # Opções específicas do cliente para conexões realizadas a 192.168.1.4 usando 
     # somente o protocolo 2
     Host 192.168.1.4
        # As 2 linhas abaixo ativam o redirecionamento de conexões do X
        ForwardAgent yes
        ForwardX11 yes
        PasswordAuthentication yes
        Port 22
        Protocol 2
        Cipher blowfish
     
     # Opções específicas do cliente para conexões realizadas a 192.168.1.5 usando 
     # somente o protocolo 1
     Host 192.168.1.5
        # As 2 linhas abaixo desativam o redirecionamento de conexões do X
        ForwardAgent no
        ForwardX11 no
        PasswordAuthentication yes
        Port 22
        Protocol 1
        Cipher blowfish
     
     #   CheckHostIP yes
     #   RhostsAuthentication no
     #   RhostsRSAAuthentication yes
     #   RSAAuthentication yes
     #   FallBackToRsh no
     #   UseRsh no
     #   BatchMode no
     #   StrictHostKeyChecking yes
     #   IdentityFile ~/.ssh/identity
     #   IdentityFile ~/.ssh/id_dsa
     #   IdentityFile ~/.ssh/id_rsa1
     #   IdentityFile ~/.ssh/id_rsa2
     #   EscapeChar ~

15.2.1.2 Cliente ssh para Windows

O putty é um cliente ssh Win32 que possui suporte aos protocolos versão 1 e 2 do ssh, aceita compactação além de funcionar também como cliente telnet. Seu tamanho é pequeno, apenas um executável e requer 220KB de espaço em disco. Ele pode ser baixado de http://www.chiark.greenend.org.uk/~sgtatham/putty/.

Outra alternativa é o MindTerm, este é baseado em Java e pode inclusive ser executado como um applet em uma página web. Este programa é encontrado em http://www.mindbright.se/mindterm/.

15.2.2 scp

Permite a cópia de arquivos entre o cliente/servidor ssh. A sintaxe usada por este comando é a seguinte:

scp [origem] [destino]

Os parâmetros de origem e destino são semelhantes ao do comando cp mas possui um formato especial quando é especificado uma máquina remota:

A opção -C é recomendável para aumentar a taxa de transferência de dados usando compactação. Caso a porta remota do servidor sshd seja diferente de 22, a opção -P porta deverá ser especificada (é "P" maiúscula mesmo, pois a -p é usada para preservar permissões/data/horas dos arquivos transferidos). 

     Exemplos:
     # Para copiar um arquivo local chamado /pub/teste/script.sh para 
     # meu diretório pessoal em ftp.sshserver.org
     scp -C /pub/teste/script.sh gleydson@ftp.sshserver.org:~/
     
     # Para fazer a operação inversa a acima (copiando do servidor remoto para o local) 
     # é só inverter os parâmetros origem/destino: 
     scp -C gleydson@ftp.sshserver.org:~/script.sh /pub/teste
     
     # Para copiar o arquivo local chamado /pub/teste/script.sh para 
     # o diretório /scripts dentro do meu diretório pessoal em ftp.sshserver.org 
     # com o nome teste.sh
     scp -C /pub/teste/script.sh gleydson@ftp.sshserver.org:~/scripts/teste.sh
     
     # O exemplo abaixo faz a transferência de arquivos entre 2 computadores remotos: 
     # O arquivo teste.sh é lido do servidor server1.ssh.org e copiado para 
     # server2.ssh.org (ambos usando o login gleydson)
     scp -C gleydson@server1.ssh.org:~/teste.sh gleydson@server2.ssh.org:~/

15.2.2.1 Cliente scp para Windows

O pscp faz a tarefa equivalente ao scp no windows, e pode ser baixado de http://www.chiark.greenend.org.uk/~sgtatham/putty/.

15.2.3 sftp

Permite realizar transferência de arquivos seguras através do protocolo ssh. A conexão e transferências são realizadas através da porta 22 (ainda não é possível modificar a porta padrão). A sintaxe para uso deste comando é a seguinte:

sftp usuario@host_remoto

Compactação pode ser especificada através da opção -C. Um arquivo contendo os comandos usados na seção sftp poderá se especificado através da opção -b arquivo para automatizar tarefas.

OBS1: Para desativar o servidor sftp, remova a linha SubSystem sftp /usr/lib/sftp-server (que inicializa o sub-sistema ftp) do arquivo /etc/ssh/sshd_config e reinicie o servidor sshd.

OBS2: O suporte ao programa sftp somente está disponível ao protocolo ssh versão 2 e superiores.

OBS3: Algumas opções comuns do cliente ftp padrão (como mget) ainda não estão disponíveis ao sftp. Veja a página de manual para detalhe sobre as opções disponíveis.

15.3 Servidor ssh

15.3.1 sshd

Este é o daemon de controle da conexão encriptada via protocolo ssh, transferência de arquivos e shell interativo. As opções de linha de comando estão disponíveis em Opções de linha de comando, Seção 15.1.10. Seu arquivo de configuração principal é /etc/ssh/sshd_config, um exemplo e descrição das opções deste arquivo é encontrada em Exemplo de sshd_config com explicações das diretivas, Seção 15.3.8.

OBS1: É recomendável que o arquivo /etc/ssh/sshd_config seja lido somente pelo dono/grupo, por conter detalhes de acesso de usuários, grupos e intervalo entre a geração de chave de seção.

OBS2: Se estiver ocorrendo falhas no acesso ao servidor ssh, verifique as permissões nos arquivos /etc/hosts.allow e /etc/hosts.deny (o nome do serviço é sshd). Mesmo operando como daemon, o servidor utiliza estes arquivos para fazer um controle de acesso adicional.

15.3.2 Controle de acesso

É definido pelas opções ListenAddress, AllowUsers, DenyUsers, AllowGroups, DenyGroups e PermitRootLogin do arquivo de configuração sshd_config (veja Exemplo de sshd_config com explicações das diretivas, Seção 15.3.8) e via tcpd (arquivos hosts.allow e hosts.deny). Veja O mecanismo de controle de acessos tcpd, Seção 4.8.3.

15.3.3 Usando autenticação RSA/DSA - chave pública/privada

Este método de autenticação utiliza o par de chaves pública (que será distribuído nas máquinas que você conecta) e outra privada (que ficará em seu diretório pessoal) para autenticação. A encriptação e decriptação são feitas usando chaves separadas e não é possível conseguir a chave de decriptação usando a chave de encriptação. É possível inclusive gerar uma chave sem senha para efetuar o logon em um sistema ou execução de comandos remotos (este esquema é um pouco mais seguro que os arquivos ~/.rhosts e ~/.shosts).

Siga os seguintes passos para se autenticar usando RSA 1 - usada na versão 1 do ssh:

  • Gere um par de chaves pública/privada usando o comando: 

         ssh-keygen

    Um par de chaves RSA versão 1 será gerado com o tamanho de 1024 bits por padrão, garantindo uma boa segurança/performance, e salvas no diretório ~/.ssh com o nome identity e identity.pub. Para alterar o tamanho da chave use a opção -b tamanho. Depois de gerar a chave, o ssh-keygen pedirá uma frase-senha (é recomendável ter um tamanho maior que 10 caracteres e podem ser incluídos espaços). Se não quiser digitar uma senha para acesso ao sistema remoto, tecle <Enter> quando perguntado. Mude as permissões do diretório ~/.ssh para 750.

    A opção -f especifica o diretório e nome das chaves. A chave pública terá a extensão .pub adicionada ao nome especificado.

    ATENÇÃO Nunca distribua sua chave privada, nem armazene-a em servidores de acesso públicos ou outros métodos que permitem outros terem acesso a ela. Se precisar de uma cópia de segurança, faça em disquetes e guarde-a em um lugar seguro.

  • Instale a chave pública no servidor remoto que deseja se conectar, por exemplo, www.sshserver.org: 

         ssh-copy-id -i ~/.ssh/identity gleydson@www.servidorssh.org

    A função do utilitário acima é entrar no sistema remoto e adicionar a chave pública local ~/.ssh/identity.pub no arquivo /home/gleydson/.ssh/authorized_keys do sistema remoto www.sshserver.org. O mesmo processo poderá ser feito manualmente usando os métodos tradicionais (ssh/scp). Caso o arquivo remoto /home/gleydson/.ssh/authorized_keys não existe, ele será criado. Seu formato é idêntico ao ~/.ssh/know_hosts e contém uma chave pública por linha.

  • Agora utilize o ssh para entrar no sistema remoto usando o método de chave pública/privada. Entre com a senha que usou para gerar o par de chaves público/privado (ele entrará diretamente caso não tenha digitado uma senha).

    • Para autenticar em uma versão 2 do ssh (usando chave RSA 2 ou DSA):

  • Gere um par de chaves pública/privada usando o comando: 

         ssh-keygen -t rsa -f ~/.ssh/id_rsa
     
     ou 
     
     ssh-keygen -t dsa -f ~/.ssh/id_rsa

    Um par de chaves RSA 2/DSA será gerado. Para alterar o tamanho da chave use a opção -b tamanho. Depois de gerar a chave, o ssh-keygen pedirá uma frase-senha (é recomendável ter um tamanho maior que 10 caracteres e podem ser incluídos espaços). Se não quiser digitar uma senha para acesso ao sistema remoto, tecle <Enter> quando perguntado. Mude as permissões do diretório ~/.ssh para 750.

    ATENÇÃO Nunca distribua sua chave privada, nem armazene-a em servidores de acesso públicos ou outros métodos que permitem outros terem acesso a ela. Se precisar de uma cópia de segurança, faça em disquetes e guarde-a em um lugar seguro.

  • Instale a chave pública no servidor remoto que deseja se conectar copiando o arquivo com: 

         scp ~/.ssh/id_rsa.pub usuario@servidorremoto:~/.ssh/authorized_keys2
     ou
     scp ~/.ssh/id_dsa.pub usuario@servidorremoto:~/.ssh/authorized_keys2
     (caso tenha gerado a chave com a opção -t dsa)

    Caso o arquivo remoto /home/gleydson/.ssh/authorized_keys2 não existe, ele será criado. Seu formato é idêntico ao ~/.ssh/know_hosts2 e contém uma chave pública por linha.

  • Agora utilize o ssh para entrar no sistema remoto usando o método de chave pública/privada. Entre com a senha que usou para gerar o par de chaves público/privado (ele entrará diretamente caso não tenha digitado uma senha).

    • OBS: Deverá ser levado em consideração a possibilidade de acesso físico ao seu diretório pessoal, qualquer um que tenha posse de sua chave privada poderá ter acesso ao sistema remoto. O tipo de chave criada por padrão é a rsa1 (compatível com as versões 1 e 2 do ssh). A opção -t [chave] poderá ser usada (ao gerar a chave) para selecionar o método de criptografia:

    Para trocar a senha utilize o comando: ssh-keygen -p -t tipo_chave -f ~/.ssh/identity - será pedida sua senha antiga e a nova senha (no mesmo estilo do passwd). Opcionalmente você pode utilizar a sintaxe: ssh-keygen -p -f ~/.ssh/identity -P senha_antiga -N senha_nova, que troca a senha em um único comando (útil para ser usado em scripts junto com a opção -q para evitar a exibição de mensagens de saída do ssh-keygen).

    15.3.4 Execução de comandos específicos usando chaves

    Com o uso de chaves também é possível o uso do ssh para execução de comandos específicos em máquinas remotas, isto é possível com os novos recursos da versão 3 do ssh. Para fazer isto, siga os passos Usando autenticação RSA/DSA - chave pública/privada, Seção 15.3.3 para gerar um par de chaves DSA (o par RSA não aceita execução de comandos específicos) e copiar para authorized_keys2. Após isto, entre no servidor remoto e edite a chave, inserindo o comando que deverá ser executado antes da linha dds, por exemplo: 

         command="ls / -la" ssh-dss ABCAB3NzaC5555MAAACBAL3...

    Com este método é possível restringir a execução de alguns comandos/serviços além de outras possibilidades como a mudança de variáveis específicas para o comando: 

         no-port-forwarding,no-X11-forwarding,no-agent-forwarding,command="ls / -la" ssh-dss ABCAB3NzaC1kc55355MAADBBYLp...

    15.3.5 Criando um gateway ssh

    Imagine quando você deseja ter acesso a uma máquina de sua rede interna que esteja atrás de um gateway, isto é possível usando os recursos explicados em Execução de comandos específicos usando chaves, Seção 15.3.4 fazendo um redirecionamento de acesso para seu usuário da seguinte forma: 

         command="ssh -t usuario@maquina.interna" ssh-dss DAK874CKLDSAUE83da9x...

    Isto o acesso do usuário ser redirecionado automaticamente quando efetuar o logon. Caso tenha definido uma senha para a chave DSA, o usuário deverá fornecer a senha para entrar no gateway e outra para acessar sua estação de trabalho.

    OBS: Não estou levando em conta as considerações de segurança que este exemplo tem em sua rede, bem como o que pode ou não ser redirecionado. A intenção foi manter a simplicidade para entender sem dificuldades como isto é feito.

    15.3.6 Criando um tunel proxy

    Aplicações remotas podem ser abertas localmente com o uso desta técnica. Você poderá usar para acessar portas que estariam disponíveis somente através do endereço remoto, realizar conexões criptografadas ou com compactação (garantindo uma boa taxa de transferência para protocolos que usem mais texto).

    Por exemplo, para redirecionar o tráfego da porta 80 do servidor remoto para a porta 2003 local: 

         ssh -l seu_login servidor -L2003:servidor_remoto:80 -f sleep 60

    O sleep 60 tem a função de apenas deixar o tunel aberto por 60 segundos, tempo suficiente para realizarmos nossa conexão. Agora, entre no seu navegador local e acesse a porta 2003: 

         http://localhost:2003

    A opção -C também pode ser especificada junto ao ssh para usar compactação dos dados da conexão. Como notou, este recurso também é útil para fazer a administração remota de máquinas, porque o que está realizando a conexão será o IP do servidor remoto, não o seu. Da mesma forma, você poderá ter problemas caso não tenha uma boa política de distribuição de contas de máquinas em sua rede. Veja Gerenciamento de contas e cuidados para a proteção de senhas, Capítulo 11 para detalhes .

    15.3.7 Diferenças nas versões do protocolo

    Retirada da página de manual do sshd:

    Protocolo SSH versão 1

    Cada servidor possui uma chave RSA específica (1024 bits por padrão) usada para identifica-lo. Quando o sshd inicia, ele gera uma chave RSA do servidor (768 bits por padrão, valor definido por ServerKeyBits) que é recriada a cada hora (modificado por KeyRegenerationInterval no sshd_config) e permanece sempre residente na RAM.

    Quando um cliente se conecta o sshd responde com sua chave pública da máquina e chaves do servidor. O cliente ssh compara a chave RSA com seu banco de dados (em ~/.ssh/know_hosts) para verificar se não foi modificada.

    Estando tudo OK, o cliente gera um número aleatório de 256 bits, o encripta usando ambas as chaves de máquina e chave do servidor e envia este número ao servidor. Ambos os lados então usam este número aleatório como chave de seção que é usado para encriptar todas as comunicações seguintes na seção.

    O resto da seção usa um método de embaralhamento de dados convencional, atualmente Blowfish ou 3DES (usado como padrão). O cliente seleciona o algoritmo de criptografia que será usado de um destes oferecidos pelo servidor. Após isto o servidor e cliente entram em um diálogo de autenticação. O cliente tenta se autenticar usando um dos seguintes métodos de autenticação:

    A autenticação usando Rhosts normalmente é desativada por ser muito insegura mas pode ser ativada no arquivo de configuração do servidor se realmente necessário. A segurança do sistema não é melhorada a não ser que os serviços rshd, rlogind, rexecd e rexd estejam desativados (assim, o rlogin e rsh serão completamente desativados na máquina).  

    Protocolo SSH versão 2

    A versão 2 funciona de forma parecida com a 1: Cada máquina possui uma chave RSA/DSA específica usada para se identificar. A diferença é que quando o sshd inicia, ele não gera uma chave de servidor. A segurança de redirecionamento é oferecida através da concordância do uso de uma chave Diffie-Hellman. Esta concordância de chave resulta em uma seção com chave compartilhada. O resto da seção é encriptada usando um algoritmo simétrico, como Blowfish, 3DES, CAST128, Arcfour, 128 bit AES, ou 256 bit AES.

    O cliente que seleciona o algoritmo de criptografia que será usado entre os oferecidos pelo servidor. A versão 2 também possui integridade de seção feita através de um código de autenticação de mensagem criptográfica (hmac-sha1 ou hmac-md5). A versão 2 do protocolo oferece um método de autenticação baseado em chave pública (PubkeyAuthentication) e o método de autenticação convencional usando senhas.

    15.3.8 Exemplo de sshd_config com explicações das diretivas

    Abaixo segue um exemplo deste arquivo que poderá ser adaptado ao seu sistema. O objetivo é ser ao mesmo tempo útil para sua configuração e didático: 

         # Modelo personalizado para o guia Foca GNU/Linux baseado na configuração 
     # original do FreeBSD. 
     # Autor: Gleydson Mazioli da Silva
     # Data: 20/09/2001. 
     
     # Porta padrão usada pelo servidor sshd. Múltiplas portas podem ser 
     # especificadas separadas por espaços.
     Port 22
     
     # Especifica o endereço IP das interfaces de rede que o servidor sshd 
     # servirá requisições. Múltiplos endereços podem ser especificados 
     # separados por espaços. A opção Port deve vir antes desta opção
     ListenAddress 0.0.0.0
     
     # Protocolos aceitos pelo servidor, primeiro será verificado se o cliente é 
     # compatível com a versão 2 e depois a versão 1. Caso seja especificado 
     # somente a versão 2 e o cliente seja versão 1, a conexão será descartada. 
     # Quando não é especificada, o protocolo ssh 1 é usado como padrão.
     Protocol 2,1
     
     # As 4 opções abaixo controlam o acesso de usuários/grupos no sistema.
     # Por padrão o acesso a todos é garantido (exceto o acesso root se 
     # PermitRootLogin for "no"). AllowUsers e AllowGroups definem uma lista 
     # de usuários/grupos que poderão ter acesso ao sistema. Os coringas 
     # "*" e "?" podem ser especificados. Note que somente NOMES são válidos, 
     # UID e GID não podem ser especificados. 
     # 
     # As diretivas Allow são processadas primeiro e depois Deny. O método que 
     # estas diretivas são processadas é idêntico a diretiva 
     # "Order mutual-failure" do controle de acesso do Apache: 
     # O usuário deverá TER acesso via AllowUsers e AllowGroups e NÃO ser bloqueado
     # por DenyUsers e DenyGroups para ter acesso ao sistema. Se uma das diretivas 
     # não for especificada, "*" é assumido como padrão. 
     # Estas permissões são checadas após a autenticação do usuário, porque 
     # dados a ele pelo /etc/passwd e PAM são obtidos após o processo de 
     # autenticação. 
     #AllowUsers gleydson teste?
     #DenyUsers root adm
     #AllowGroups users
     #DenyGroups root adm bin
     
     # Permite (yes) ou não (no) o login do usuário root
     PermitRootLogin no
     
     # Chaves privadas do servidor (as chaves públicas possuem um ".pub" adicionado
     # no final do arquivo. 
     HostKey /etc/ssh/ssh_host_key
     HostKey /etc/ssh/ssh_host_rsa_key
     HostKey /etc/ssh/ssh_host_dsa_key
     
     # Tamanho da chave. 768 bits é o padrão
     ServerKeyBits 768
     
     # Tempo máximo para login no sistema antes da conexão ser fechada
     LoginGraceTime 600
     
     # Tempo para geração de nova chave do servidor (segundos). O padrão é 
     # 3600 segundos (1 hora). 
     KeyRegenerationInterval 3600
     
     # Ignora os arquivos ~/.rhosts e ~/.shosts
     IgnoreRhosts yes
     
     # Ignora (yes) ou não (no) os arquivos ~/.ssh/known_hosts quando for usado 
     # para a opção RhostsRSAAuthentication. Se você não confia neste mecanismo 
     # ajuste esta opção para yes.
     IgnoreUserKnownHosts no
     
     # Checa por permissões de dono dos arquivos e diretório de usuário antes de 
     # fazer o login. É muito recomendável para evitar riscos de segurança 
     # com arquivos lidos por todos os usuários. 
     StrictModes yes
     
     # Permite (yes) ou não (no) o redirecionamento de conexões X11. A segurança 
     # do sistema não é aumentada com a desativação desta opção, outros métodos
     # de redirecionamento podem ser usados
     X11Forwarding yes
     
     # Especifica o número do primeiro display que será usado para o redirecionamento
     # X11 do ssh. Por padrão é usado o display 10 como inicial para evitar conflito 
     # com display X locais
     X11DisplayOffset 10
     
     # Mostra (yes) ou não (no) a mensagem em /etc/motd no login. O padrão é "no".
     PrintMotd no
     
     # Mostra (yes) ou não (no) a mensagem de último login do usuário. O padrão é "no".
     PrintLastLog no
     
     # Permite (yes) ou não (no) o envio de pacotes keepalive (para verificar se o 
     # cliente responde. Isto é bom para fechar conexões que não respondem mas 
     # também podem fechar conexões caso não existam rotas para o cliente 
     # naquele momento (é um problema temporário). Colocando esta opção como 
     # "no" por outro lado pode deixar usuários que não tiveram a oportunidade
     # de efetuar o logout do servidor dados como "permanentemente conectados"
     # no sistema. Esta opção deve ser ativada/desativada aqui e no programa 
     # cliente para funcionar. 
     KeepAlive yes
     
     # Facilidade e nível das mensagens do sshd que aparecerão no syslogd
     SyslogFacility AUTH
     LogLevel INFO
     
     # Especifica se somente a autenticação via arquivos ~/.rhosts e /etc/hosts.equiv é 
     # suficiente para entrar no sistema. Não é muito bom usar "yes" aqui.
     RhostsAuthentication no
     
     # Mesmo que o acima com o acréscimo que o arquivo /etc/ssh/ssh_known_hosts também 
     # é verificado. Também evite usar "yes" aqui.
     RhostsRSAAuthentication no
     
     # Especifica se a autenticação via RSA é permitida (só usado na versão 1 do 
     # protocolo ssh). Por padrão "yes". 
     RSAAuthentication yes
     
     # Permite autenticação usando senhas (serve para ambas as versões 1 e 2 do ssh).
     # O padrão é "yes". 
     PasswordAuthentication yes
     
     # Se a PasswordAuthentication for usada, permite (yes) ou não (no) login 
     # sem senha. O padrão é "no".
     PermitEmptyPasswords no
     
     # Ativa senhas s/key ou autenticação PAM NB interativa. Nenhum destes é 
     # compilado por padrão junto com o sshd. Leia a página de manual do 
     # sshd antes de ativar esta opção em um sistema que usa PAM. 
     ChallengeResponseAuthentication no
     
     # Verifica se o usuário possui emails ao entrar no sistema. O padrão é "no".
     # Este módulo também pode estar sendo habilitado usando PAM (neste caso 
     # cheque a configuração em /etc/pam.d/ssh). 
     CheckMail no
     
     # Especifica se o programa login é usado para controlar a seções de shell 
     # interativo. O padrão é "no".
     UseLogin no
     
     # Especifica o número máximo de conexões de autenticação simultâneas feitas 
     # pelo daemon sshd. O valor padrão é 10. Valores aleatórios podem ser 
     # especificados usando os campos "inicio:taxa:máximo". Por exemplo, 
     # 5:40:15 rejeita até 40% das tentativas de autenticação que excedam o 
     # limite de 5 até atingir o limite máximo de 15  conexões, quando 
     # nenhuma nova autenticação é permitida.
     MaxStartups 10
     #MaxStartups 10:30:60
     
     # Mostra uma mensagem antes do nome de usuário/senha
     Banner /etc/issue.net
     
     # Especifica se o servidor sshd fará um DNS reverso para verificar se o 
     # endereço confere com a origem (isto é útil para bloquear conexões 
     # falsificadas - spoofing). O padrão é "no". 
     ReverseMappingCheck yes
     
     # Ativa o subsistema de ftp seguro. Para desabilitar comente a linha 
     # abaixo
     Subsystem	sftp	/usr/lib/sftp-server

    [ anterior ] [ Conteúdo ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ 13 ] [ 14 ] [ 15 ] [ 16 ] [ 17 ] [ 18 ] [ 19 ] [ 20 ] [ 21 ] [ próximo ]

    Guia Foca GNU/Linux

    Versão 6.43 - domingo, 05 de setembro de 2010

    Gleydson Mazioli da Silva gleydson@guiafoca.org