Configuração do servidor

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“. A maior parte das opções dentro do arquivo podem ser omitidas, pois o servidor simplesmente utiliza
valores defaults 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:

Port 22

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:

# ssh -p 2222 morimoto@192.168.0.1

Outra opção é editar o arquivo “/etc/ssh/ssh_config” (nos clientes) e alterar a porta padrão usada também 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 não existe um alvo definido, começam com um portscan genérico, onde é feita uma varredura em faixas inteiras de endereços IP, porém apenas em algumas portas conhecidas, como a 21, 22 e 80 (a fim de tornar o teste mais rápido,
embora menos preciso).

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 54232, já dificulta um pouco as coisas.

– Controle de acesso: Logo abaixo vem a opção “ListenAddress”, que permite limitar o SSH a uma única placa de rede (mesmo sem usar firewall), útil em casos de micros com duas ou mais placas. O típico caso onde
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:

ListenAddress 192.168.0.1

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:

Protocol 2,1

O protocolo SSH 1 tem alguns problemas fundamentais de segurança, por isso alguns administradores preferem desabilitar a compatibilidade com ele, aceitando apenas clientes que usam o SSH 2. Neste caso, a linha fica apenas
“Protocol 2”

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

PermitRootLogin yes

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
depois virar root usando o “su” ou “su -“. Desta forma, será preciso saber duas senhas, ao invés de saber apenas a senha do root.

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, adicione a linha:

AllowUsers joao maria

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

DenyUsers ricardo manoel

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

PermitEmptyPasswords no

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

Banner = /etc/ssh/banner.txt

– X11 Forwarding: Um pouco depois temos a opção:

X11Forwarding yes

Esta opção determina 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. Desta forma, os clientes poderão executar apenas comandos e aplicativos de modo texto.

– Módulos: 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:

Subsystem sftp /usr/lib/sftp-server

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