Configuração do servidor SSH

Você pode configurar várias opções relacionadas ao servidor SSH, incluindo a porta TCP a ser usada editando o arquivo “/etc/ssh/sshd_config“. Assim como no caso da configuração do cliente, a maior parte das opções dentro do arquivo podem
ser omitidas (pois o servidor simplesmente utiliza valores default para as opções que não constarem no arquivo), mas, de qualquer forma, é saudável especificar todas as opções que conhece: além de evitar enganos, é uma forma de praticar e memorizar as
opções.

Porta: Uma das primeiras linhas é a:

Esta é a porta que será usada pelo servidor SSH. O padrão é usar a porta 22. Ao mudar a porta do servidor aqui, você deverá usar a opção “-p” ao conectar a partir dos clientes para indicar a porta usada, como em:

Outra opção é editar o arquivo “/etc/ssh/ssh_config” (nos clientes) e alterar a porta padrão usada por eles. Mudar a porta padrão do SSH é uma boa idéia se você está preocupado com a segurança. Muitos dos ataques “casuais”
(quando o atacante simplesmente varre faixas inteiras de endereços, sem um alvo definido), começam com um portscan genérico, onde é feita uma varredura em faixas inteiras de endereços IP, procurando por servidores com portas conhecidas abertas, como a 21,
a 22 e a 80. Isso torna o teste mais rápido, permitindo localizar rapidamente um grande volume de hosts com portas abertas. A partir daí, os ataques vão sendo refinados e direcionados apenas para os servidores vulneráveis encontrados na primeira
varredura. Colocar seu servidor para escutar uma porta mais escondida, algo improvável como a porta 32456 ou a 54232 reduz sua exposição.

Controle de acesso: Logo abaixo vem a opção “ListenAddress”, que permite limitar o SSH a uma única interface de rede (mesmo sem usar firewall), útil em casos de micros com duas ou mais placas; o típico caso
em que você quer que o SSH fique acessível apenas na rede local, mas não na Internet, por exemplo. Digamos que o servidor use o endereço “192.168.0.1” na rede local e você queira que o servidor SSH não fique disponível na Internet. Você adicionaria a
linha:

Note que especificamos nesta opção o próprio IP do servidor na interface escolhida, não a faixa de IP’s da rede local ou os endereços que terão acesso a ele.

Protocolo: Atualmente utilizamos o SSH 2, mas ainda existem alguns poucos clientes que utilizam a primeira versão do protocolo. Por padrão, o servidor SSH aceita conexões de clientes que utilizam qualquer um
dos dois protocolos, o que é indicado na linha:

O protocolo SSH 1 tem alguns problemas fundamentais de segurança, por isso é recomendável desativar a compatibilidade com ele, aceitando apenas clientes que usam o SSH 2. Neste caso, a linha fica apenas:

Restringir a versão do protocolo ajuda a melhorar a segurança, pois evita que usuários utilizando clientes SSH antigos abram brechas para ataques. Existem, por exemplo, muitos clientes SSH para uso em celulares que suportam
apenas o SSH 1 e utilizam algoritmos fracos de encriptação. Desativando a compatibilidade com o SSH 1 você corta o mal pela raiz.

Usuários e senhas: Outra opção interessante, geralmente colocada logo abaixo, é a:

Esta opção determina se o servidor aceitará que usuários se loguem como root. Do ponto de vista da segurança, é melhor deixar esta opção como “no”, pois assim o usuário precisará primeiro se logar usando um login normal e
rodar comandos como root usando o “sudo” ou “su -“:

Dessa forma, é preciso saber duas senhas, ao invés de saber apenas a senha do root, eliminando a possibilidade de algum atacante obstinado conseguir adivinhar a senha de root e, assim, obter acesso ao servidor.

Por padrão, o SSH permite que qualquer usuário cadastrado no sistema se logue remotamente, mas você pode refinar isso através da opção “AllowUsers”, que especifica uma lista de usuários que podem usar o SSH. Quem não estiver
na lista, continua usando o sistema localmente, mas não consegue se logar via SSH. Isso evita que contas com senhas fracas, usadas por usuários que não têm necessidade de acessar o servidor remotamente coloquem a segurança do sistema em risco. Para
permitir que apenas os usuários “joao” e “maria” possam usar o SSH, por exemplo, adicione a linha:

Você pode ainda inverter a lógica, usando a opção “DenyUsers”. Neste caso, todos os usuários cadastrados no sistema podem fazer login, com exceção dos especificados na linha, como em:

Outra opção relacionada à segurança é a:

Esta opção faz com que qualquer conta sem senha fique automaticamente desativada no SSH, evitando que alguém consiga se conectar ao servidor “por acaso” ao descobrir a conta desprotegida. Lembre-se de que a senha é
justamente o ponto fraco do SSH. De nada adianta usar 2048 bits de encriptação se o usuário escreve a senha em um post-it colado no monitor, ou deixa a senha em branco.

Banner: Alguns servidores exibem mensagens de advertência antes do prompt de login, avisando que todas as tentativas de acesso estão sendo monitoradas ou coisas do gênero. A mensagem é especificada através
da opção “Banner”, onde você indica um arquivo de texto com o conteúdo a ser mostrado, como em:

X11 Forwarding: Além de ser usada na configuração dos clientes, a opção “X11Forwarding” pode ser também incluída na configuração do servidor:

Ela determina se o servidor permitirá que os clientes executem aplicativos gráficos remotamente. Se o servidor for acessado via Internet ou se possui um link lento, você pode deixar esta opção como “no” para economizar
banda. Desta forma, os clientes poderão executar apenas comandos e aplicativos de modo texto. Note que ao usar “X11Forwarding no” o encaminhamento é recusado pelo próprio servidor, de forma que o usuário não consegue rodar aplicativos gráficos mesmo que a
opção esteja ativa na configuração do cliente.

– SFTP: O SSH inclui um módulo de transferência de arquivos (o SFTP), que veremos em detalhes a seguir. Ele é ativado através da linha:

É realmente necessário que esta linha esteja presente para que o SFTP funcione. Comente esta linha apenas se você realmente deseja desativá-lo.