Tag ssh (Página 10) - Userlinux.net

Al hilo de la anterior entrada y buscando alternativas para bloquear todos esos ataques por fuerza bruta (bruteforce) al servicio de administración remota SSH he encontrado la solución ideal -o lo que más se le aproxima-, sin descartar las anteriores.

La regla mágica hace uso de una nueva característica de Packet Filter (desde OpenBSD-3.7) llamada max-src-conn-rate. Lo que venimos a decirle a nuestro firewall es que permita todas las conexiones ssh con la salvedad de que no se sobrepasen 3 intentos en menos de 30 segundos, en dicho caso se agregará la IP del atacante a una lista llamada ssh-bruteforce, en pf.conf:

A veces las cosas pasan porque tienen que pasar y no hay vuelta de hoja. Si a un administrador de sistemas le cortamos el acceso ssh a un servidor remoto (tanto virtual como físicamente) es como si inutilizáramos el brazo ejecutor que le otorga el poder que buenamente tiene.

Esto a veces pasa de forma consciente y otras -las peores- sin el menor indicio. Intentando esto último obtengo un mensaje tal que así:

Versiones anteriores a la 4.3 de OpenSSH son vulnerables de forma remota a través de una condición de carrera que dadas unas circunstancias podría permitir no solo ataques de denegación de servicio, también la ejecución de código arbitrario de forma remota.

Podríamos definir este bug como crítico, recomendando una actualización a la última versión (4.4) cuanto antes.

A veces existe la imperiosa necesidad de configurar el acceso SSH sin clave por diversos motivos. Supongamos que cada poco tiempo tenemos que transferir archivos de un ordenador a otro de forma segura (por ssh o scp se me ocurre). Es un lío andar poniendo la contraseña cada vez que lo necesitemos.

Podemos solucionar nuestro problema haciendo que un equipo confíe en el otro. Mirándolo de otra forma podemos pensar que es inseguro, pero en ciertas ocasiones merece la pena tener esta configuración, más aún si los 2 equipos son propiedad de la misma persona :) Un caso práctico al que se puede aplicar todo esto es en una copia de seguridad de una máquina a otra a través de rsync o scp, así que allá vamos:

Para empezar tenemos que generar una clave dsa pública local que posteriormente exportaremos al ordenador remoto:

luser@local# ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/luser/.ssh/id_dsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /luser/.ssh/id_dsa.
Your public key has been saved in /luser/.ssh/id_dsa.pub.
The key fingerprint is:
aa:rr:aa:ss:ff:rr:ee:nn:aa:dd:aa:ll:aa:rr:gg:aa 
luser@local#

La passphrase la dejamos en blanco, pues buscamos eso, no interactuar en el ssh. Una vez generada esa clave, debemos pasarla de forma segura (es muy importante no pasarla por ftp, mail o similares) a la máquina remota. Podemos hacerlo de la siguiente manera:

luser@local# scp .ssh/id_dsa.pub luser@remote:/home/luser/.ssh/authorized_keys2
luser@local#

O más sencillo todavía:

$ ssh-copy-id -i ~/.ssh/id_dsa.pub user@remote.machine.com

Una vez pasada la clave a la máquina remota estamos en condiciones de hacer un ssh sin contraseña alguna:

luser@local# ssh remote ls
.bash_history
.bashrc
pipiculas
tonteridas
...
luser@local#

Este mini-post está inspirado en el de Natxo Morell, quería tener la anotación en mi bitácora para poder consultar un utilísimo truck & tip cuando no lo recuerde, mi memoria a veces falla. Gracias Natxo.