Raúl Santos
Dado o comentário do João Moreno ao meu artigo sobre como pôr um Ubuntu a servir virtual hosts com Apache e MySQL, achei que seria útil deixar aqui instruções sobre como melhor proteger o servidor de SSH através de um par de chaves pública/privada.
Os primeiros passos deverão ser efectuados na nossa máquina local. Assumindo que estamos a utilizar *nix (Linux, *BSD, Mac OS X, etc. - em Windows têm de utilizar o Putty) e que já temos o openssh instalado na nossa máquina local, o procedimento é relativamente simples:
ssh-keygen -t rsa
Escolhemos o ficheiro onde gravar a chave (pode dar jeito se gerarmos mais que uma chave, para máquinas diferentes, por exemplo) e uma password. A password é especialmente importante para quem utiliza computadores portáteis (ou outras situações onde os seus ficheiros possam ser roubados), porque se não tiverem uma password na vossa chave privada (o primeiro ficheiro gerado, aquele que escolhemos onde gravar) e alguém vos roubar o portátil, essa pessoa pode utilizar a chave para aceder a tudo o que “trancámos” com ela. Nada bom… De notar que esta password não tem nada que ver com a password usada para aceder à máquina remota; é apenas uma password para permitir a utilização da chave.
Isto vai gerar dois ficheiros. Imaginando que deixámos o nome do ficheiro como o default “id_rsa”, vamos ter então os ficheiros ~/.ssh/id_rsa e ~/.ssh/id_rsa.pub. O primeiro, id_rsa, é a nossa chave privada. Nunca partilhem esta chave com ninguém, mesmo que vos digam que têm de o fazer! Se alguém vos disser isto, está a tentar enganar-vos. O segundo ficheiro, id_rsa.pub é a chave pública e esta sim, pode ser partilhada - dependendo da utilização que quiserem dar às chaves, poderão até ter de o fazer.
Agora que temos as duas chaves na nossa máquina local, temos de colocar a chave pública no servidor. Seguindo os exemplos do artigo sobre como pôr um Ubuntu a servir virtual hosts com Apache e MySQL, vamos assumir que temos uma máquina acessível pelo domínio “omeuvps.com” e que nela temos um utilizador chamado “eumesmo”. Para copiar a chave pública para o servidor, basta fazer o seguinte:
scp ~/.ssh/id_rsa.pub [email protected]:~/
Neste momento temos a chave pública no servidor, na directoria do nosso utilizador. Precisamos agora de a adicionar à lista de chaves autorizdas. Para isso precisamos de entrar no servidor, pelo que os comandos que vamos fazer a partir de agora serão todos executados na máquina remota. Vamos a isso:
ssh [email protected]
mkdir .ssh
cat id_rsa.pub » .ssh/authorized_keys
rm id_rsa.pub
O que acabámos de fazer foi: depois de entrar no servidor, na primeira linha, criámos (caso não existisse) a directoria .ssh e copiámos o conteúdo da nossa chave pública (não é mais que um ficheiro de texto) para dentro (mais precismente, para o fim) do ficheiro ~/.ssh/authorized_keys. Isto fará com que a nossa chave seja reconhecida quando tentarmos entrar com ela.
Resta-nos configurar o servidor de SSH para aceitar autenticação por chave. Vamos editar o ficheiro de configuração:
sudo nano /etc/ssh/sshd_config
e adicionar ou alterar as linhas dos parâmetros RSAAuthentication e PubkeyAuthentication para isto:
RSAAuthentication yes
PubkeyAuthentication yes
Não vamos desactivar já o acesso por password, pois primeiro queremos testar para ver se o acesso por chave funciona. Vamos dizer ao servidor de SSH para reler as suas configurações:
sudo /etc/init.d/ssh reload
Agora vamos abrir outra consola na nossa máquina local, para não fecharmos a ligação que temos aberta (não vá o diabo tecê-las - won’t go the devil to weave them - e o servidor de SSH deixar de aceitar ligações), e vamos testar a nossa nova ligação.
Se utilizámos o nome default do ficheiro de chave privada (id_rsa), então deveremos conseguir ligar-nos com este comando:
ssh remoteuser@remotehost
Se fizemos tudo correctamente, ser-nos-á pedida uma password. De notar que essa passoword é a password para aceder à chave e não a password que utilizávamos anteriormente (a password do utilizador “eumesmo”). Depois de introduzir a password da chave, entramos no servidor e temos uma nova ligação por SSH estabelecida, tal como a que tínhamos anteriormente.
Duas possíveis diferenças:
- Se não dermos uma password ao gerar a chave, não nos será pedida nenhuma password para entrar. Isto demonstra o perigo que representa uma chave privada sem estar protegida por password.
- Se demos um nome diferente ao ficheiro, o ssh não vai reconhecê-lo e por isso precisamos de lhe dar uma ajuda. Em vez do comando anterior, usamos este:
ssh -i ~/.ssh/nome_da_chave [email protected]substituíndo, obviamente "nome_da_chave" pelo nome do ficheiro que criámos inicialmente.
Após verificarmos que conseguimos entrar no servidor com a nossa chave, podemos então desactivar o acesso por password, pois não faz muito sentido manter os dois. Editamos novamente o ficheiro de configuração:
sudo nano /etc/ssh/sshd_config
e adicionamos/alteramos as seguintes linhas:
ChallengeResponseAuthentication no
PasswordAuthentication no
Recarregamos a configuração do servidor:
sudo /etc/init.d/ssh reload
e está feito!
Se nos tentarmos ligar agora sem utilizar a chave privada, o servidor irá ignorar a nossa tentativa de ligação e mostrar-nos-á a mensagem “Permission denied (publickey).”.
Uma vez perguntaram-me qual era a vantagem de usar chaves privadas, se a pessoa tinha que introduzir uma password na mesma. Acontece que as chaves não são uma forma de tornar a nossa vida mais cómoda ao não ter que introduzir uma password, mas sim uma forma de tornar o processo de autenticação mais seguro e até permitir certas situações, como uma aplicação automatizada (um script de backup, por exemplo) efectuar um login noutra máquina sem ter de possuir a password em texto legível.
No entanto é possível não ter de fornecer a password sempre que nos ligamos ao servidor, utilizando o ssh-agent. Claro que envolve riscos, como não podia deixar de ser, e como eu não concordo que a segurança deva ser reduzida (pelo menos não tanto) em nome do conforto, não vou falar disso.
Outra aplicação que pode ser útil para quem não gosta de mexer na linha de comandos, o seahorse. Já não me recordo se vem instalada de raíz no Ubuntu desktop mas se não vier podem instalá-la com o apt-get.
PS - Exmo. Sr. Primeiro Ministro, se vier ler isto, sugiro que implemente mecanismos semelhantes em todas as suas comunicações. Tendo em conta o actual estado de eventos, eu diria que já lhe teria dado jeito…