# Guia do Linux/Avançado/Servidor ssh/Servidor ssh
## Servidor ssh
### 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 [#s-s-ssh-opcoescmd 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 [#s-s-ssh-server-sshd_config Exemplo de sshd_config com explicações das diretivas, Seção 15.3.8].
OBS1: O ssh, após a instalação, funciona passando como parâmetro o IP do computador destino. Para usar nomes em vez de IPs (ou seja, para usar ssh computarname em vez de ssh 100.99.98.97), é preciso fazer alguma magia negra que não é explicada aqui nem em nenhum outro tutorial.
OBS2: É 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.
OBS3: 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.

### Controle de acesso

É definido pelas opções ListenAddress, AllowUsers, DenyUsers, AllowGroups, DenyGroups e PermitRootLogin do arquivo de configuração sshd_config (veja [#s-s-ssh-server-sshd_config Exemplo de sshd_config com explicações das diretivas, Seção 15.3.8]) e via tcpd (arquivos hosts.allow e hosts.deny). Veja [ch-rede.html#s-rede-seg-tcpd O mecanismo de controle de acessos tcpd, Seção 4.8.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:
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:
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:
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:
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:
** rsa1 - Cria uma chave rsa compatível com a versão 1 e 2 do ssh (esta é a padrão).
** rsa - Cria uma chave rsa compatível somente com a versão 2 do ssh.
** dsa - Cria uma chave dsa compatível somente com a versão 2 do ssh.
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).

### 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 [#s-s-ssh-server-rsaauth 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:
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:

### 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 [#s-s-ssh-server-cmdkey 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:
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.

### 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:
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:
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 [ch-d-contas.html Gerenciamento de contas e cuidados para a proteção de senhas, Capítulo 11] para detalhes .

### 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:
*   * ~/.rhosts ou ~/.shosts (normalmente desativada).
*   * ~/.rhosts ou ~/.shosts combinado com autenticação RSA (normalmente desativada).
*   * Autenticação RSA por resposta de desafio.
*   * Autenticação baseada em senha.
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.

### 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: