La intención en este artículo es echar un poco de luz a Secure SHell… Un poco más de lo hecho previamente, que quizás fué más una «receta» para salir del paso…
Veremos con cierta profundidad los aspectos más relevantes como: paliar un ataque de «fuerza bruta», acceder sin ingresar una clave (útil para automatización de tareas), tener acceso irrestricto si podemos verificar nuestra identidad, entre otros pormenores…
SSH: Secure SHell
Tal es el nombre de este «demonio» que, en Linux, y nos permite acceder por consola desde casi cualquier lugar a todo equipo en el que esté instalado. (SIC).
«Casi» porque, si el dispositivo que utilizamos para ingresar permite que escribamos texto (más o menos cómodos), podremos ejecutar desde él los comandos necesarios para llevar las acciones deseadas. Este «casi» comienza con, por ejemplo, un ordenador de escritorio y (parecería por lógica) terminar en un ordenador portátil; pasando por tabletas, celulares, televisores inteligentes y ese etcétera que aún no está a nuestro alcance, pero…
«Todo equipo» que pueda correr un demonio SSH, podrá ser alcanzado, con algunas limitaciones (claro).El sistema operativo Android, por ejemplo, no dejan de ser un Linux, recortado, y está presente en muchos ¿electrodomésticos? y «gadgets» que de poder ingresar a la «tienda» puede ser capaz de instalar una de las tantas adaptaciones de Secure SHell que hay en ella.
Esto da un «paisaje» que, si nos preocupa la seguridad e intimidad, puede ponernos un «poquito» nerviosos… Según el nivel de «paranoia» que cada uno posea.
«El hecho que sea paranoico no descarta que me estén persiguiendo…»
reza un refrán popular…
¿Desactivar SSH?
Allí donde NO sea necesario, desactivar SSH es una medida de seguridad que, no sólo es simple, sino que ahorra recursos y evita problemas futuros (o presentes)…
Pero no siempre es viable, por ejemplo, en los servidores o dispositivos que tienen una interfaz de manejo «elemental» y necesitamos tener un poco más de «control» sobre su funcionamiento. Un caso trivial sería un NAS, un router, un switch, y la lista empieza a hacerse larga…
Conociendo SSH
Hace un tiempo atrás escribí una guía «somera», dando indicaciones muy específicas; más tarde comenté cómo evitar poner claves o automatizar procesos por ese canal acreditando identidad y hace poco mencioné cómo instalar este demonio en un servidor de pruebas en una máquina virtual.
Me tomaré el tiempo de explicarles, desde cómo instalarlo hasta cómo configurarlo, con el agregado de poder acceder al equipo que lo tenga instalado sin necesidad de utilizar una clave llevando con nosotros siempre la posibilidad de acreditarnos…
Instalar SSH
La presente guía está basada en CentOS, aprovechando que (de seguir aquella en la que indico cómo tener un servidor virtual) ya debería tener uno de prueba… Es un CentOS 6.7 y, si bien algunas ubicaciones pueden variar y otros comandos serán notoriamente diferentes, puede aplicarse en otras distribuciones Linux adaptando según sea necesario. Aquellos que lo deseen, pueden aportar las diferencias en el área de comentarios aquí abajo.
# yum install ssh-server
Y ya está instalado…
Configurando el Servicio SSH
Acá está la clave de la seguridad de nuestro «servidor» SSH…
Entendamos como «servidor» al QUE estará esperando que nos conectemos, es decir, lo que llamamos el «remoto«…
OBSERVACIÓN: Para no marear, suponiendo que llegan a esta guía como una suerte de «receta» efectiva y funcional, trataré de cubrir las medidas de seguridad más elementales y, según entienda pertinente, abordaré otros parámetros que pueden ser útiles… Descarto que a esta guía lleguen especialistas que podrían cuestionar mi humilde aporte, y aquellos que quieran «profundizar» y/o «endurecer» la configuración, a su disposición está en la web la descripción de cada parámetro para su experimentación.
«Sin rizar el rizo», entonces, procederemos a editar el archivo /etc/ssh/sshd_config donde editaremos los siguientes parámetros según su función:
(Ordenados por el nombre del parámetro, puede diferir el orden en el archivo de configuración)
Parámetros Elementales
Parámetro | Valor por defecto | Valor sugerido | Función |
AllowUsers | No Activo | Usuarios, separados por espacio, que tienen permitido el acceso | Enumerar los usuarios que tienen permitido el acceso por SSH |
LoginGraceTime | 600 | 30 | El servidor espera N segundos a que el usuario ingrese su clave. Luego, cierra la conexión. |
MaxAuthTries | 6 | 3 | Cantidad de intentos para ingresar la clave. Si nos equivocamos 3 veces, no estamos atentos a lo que estamos escribiendo. Incluso, un valor de 2 debería alcanzar. |
MaxStartups | 10 | ¿3? | La cantidad de conexiones activas que permite el servidor. Si sólo es una persona quien accede, con 3 sobra: una para ejecutar, otra para monitorear los logs y la tercera por si algo sale mal y debemos volver atrás una modificación. |
PermitRootLogin | yes | no | root no debería ni siquiera poder ingresar en la máquina de modo local (ya expliqué el por qué) |
Port | 22 | Cualquier valor que no entre en conflicto con un servicio a utilizar. Se puede consultar esta lista oficial. Ej: 28022 |
El servidor esperará las conexiones por el puerto indicado. Tener en cuenta de abrir dicho puerto en iptables o el firewall, aparte de observarlo en las NAT de ser necesario (en una Virtual Box, por ejemplo). |
Parámetros Optativos
Parámetro | Valor por defecto | Valor sugerido | Función |
AllowGroups | No Activo | Grupos Permitidos | Enumerar los grupos que tienen permitido el ingreso. Los usuarios que pertenezcan a dicho grupo, podrán acceder. |
ListenAddress | No Activo | IP’s de las interfaces del servidor por las que se puede acceder al servicio | Evita que las conexiones SSH sean por cualquiera de las interfaces de red que posee el servidor. Si tiene sólo una, no tiene sentido utilizarlo |
X11Forwarding | no | yes (Depende de la configuración del servidor) |
Permitirá ejecutar aplicaciones «gráficas» si el servidor posee esa capacidad. Útil para el acceso a nuestro ordenador de escritorio, por ejemplo. Si no tiene un gestor de ventanas (gnome, unity, mate, etc.) puede dejarse sin activar. |
Ejemplo de archivo de configuración sugerido (sólo las partes relevantes):
# Port 22 Port 28022 ... #LoginGraceTime 600 LoginGraceTime 30 ... #PermitRootLogin yes PermitRootLogin no ... AllowUsers nombre_usuario otro_usuario ... # MaxAuthTries 6 MaxAuthTries 3 ... #MaxSessions 10 MaxSessions 3 ... PasswordAuthentication yes #ChallengeResponseAuthentication yes ChallengeResponseAuthentication no #X11Forwarding yes X11Forwarding no ...
Una vez editados estos parámetros, elementales y optativos incluidos, podremos activar nuestro servidor e indicarle que inicie cuando arranque, con las siguientes órdenes:
# chkconfig sshd on # service sshd start
Con el primero lo «activamos» para cada reinicio, con el segundo lo ponemos en ejecución para la sesión actual… Hasta aquí lo hecho en el servidor que recibirá las conexiones.
NOTA: En este artículo hago referencia al uso desde linux; quizás en otro marcaré las diferencias para utilizar desde Windows con MTPuTTY… (No es más que un «envoltorio» de PuTTY que permite tener varias conexiones simultáneas en una misma ventana y otras bondades más), aunque es tan popular su uso que hay mucha referencia en internet sobre ellos…
Podremos ahora probar nuestra configuración desde una consola Linux:
$ ssh -p PUERTO usuario@ip_del_servidor
Donde puerto es el indicado en reemplazo del 22 (por defecto), usuario el que mencionamos como habilitado para el acceso y la ip_del_servidor la que tiene el mismo.
Supongamos que el servidor SSH tiene una ip 10.0.2.15 y el puerto que le indicamos al servicio (ver arriba) es el 28022…
$ ssh -p 28022 [email protected]
Accediendo sin claves
Una de las «incomodidades», sobre todo al momento de automatizar acciones, es que el servidor SSH pide una clave para su ingreso…
Esto se puede evitar por medio de claves SSH: un archivo que contiene una secuencia de caracteres que contiene nuestra «clave pública» y, que sin necesidad de ingresar la «clave» tipeada previamente al momento de crear nuestro usuario, nos identifica en un servidor remoto. Dicho archivo podemos llevarlo con nosotros de modo tal que, desde cualquier «cliente» (la máquina que se conecta al «remoto»), podamos conectarnos sin «exponer» al ojo sagaz o «key loggers» nuestra preciada «contraseña». Por cierto, «key loggers» es cualquier proceso oculto que registra la combinación de teclas del usuario para poner en evidencia información sensible. Sabrán nuestro usuario, pero no la clave… Casi…
Para ello crearemos nuestro par de claves pública-privada, si es que no existen ya… si tenemos en nuestra carpeta home una carpeta de nombre .ssh (con el punto delante), dentro de ella deberían existir dos archivos: id_rsa y id_rsa.pub. Si no existen, o la carpeta tampoco, los crearemos de este modo en el ordenador nuestro:
$ ssh-keygen -t rsa Generating public/private rsa key pair. Enter file in which to save the key (/home/esteban/.ssh/id_rsa): Created directory '/home/esteban/.ssh'. Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/esteban/.ssh/id_rsa. Your public key has been saved in /home/esteban/.ssh/id_rsa.pub. The key fingerprint is: 00:11:22:33:44:55:66:77:88:99:aa:bb:cc:dd:ee:ff esteban@mercurio The key's randomart image is: +--[ RSA 2048]----+ | E-/5| | .4fd0 | | sh= | | . xx| | . S , | | v B . | | . * + . | | . = | | g | +-----------------+
A todo respondemos con enter, y tendremos un resultado similar al que se ve aquí arriba.
El archivo id_rsa es nuestra clave privada y, como habrán deducido, id_rsa.pub es la pública.
Copiaremos, entonces, el archivo id_rsa.pub al servidor remoto:
$ scp -P 28022 ~/.ssh/id_rsa.pub [email protected]:/tmp/id_rsa.esteban
Luego de ingresar la clave, se habrá transferido el archivo, ingresamos al servidor remoto:
$ ssh -p 28022 [email protected]
Y allí lo que haremos es lo siguiente: copiaremos el contenido de nuestra clave pública en un archivo que SSH utiliza para almacenarlas para su comparación… Aquí se verán los pasos para el usuario root del servidor remoto, si tuviéramos otro usuario para conectarnos, deberá hacerse en la carpeta home de dicho usuario…
# cd ~ # mkdir -p .ssh # cat /tmp/id_rsa.esteban >> ~/.ssh/authorized_keys # rm /tmp/id_rsa.esteban # exit
NOTA: observar que se «concatena» la clave pública al archivo que las contiene, y éste puede tener tantas claves públicas como sean necesarias…
Si ahora, reingresamos al servidor remoto, observarán que ya no nos pide la clave, esto es porque se intercambiaron las recién generadas. Esta operación puede (y debería) hacerse por cada usuario que tendrá acceso al servidor…
Accediendo desde cualquier terminal
No deja de ser práctico llevar con nosotros nuestra clave privada (id_rsa) para que de esa manera, sin importar dónde estemos, el servidor remoto nos reconozca y poder ingresar al él… Sea lo que fuere que almacena nuestra clave privada (pendrive, almacenamiento en un celular, disco portátil, etc) lo conectamos al equipo desde el cual nos conectaremos y tomamos nota de la ruta de acceso a dicho archivo.
En este caso demostraré cómo lo realizo desde un Ubuntu, utilizando un pendrive… Dado que Ubuntu automáticamente monta el pendrive en una carpeta llamada media bajo el nombre del usuario en curso, para conectarme utilizaría la siguiente línea:
$ ssh -i /media/esteban/MiPendrive/claves/id_rsa.ejemplo \ -p 28022 [email protected]
Explico: el parámetro -i le indica a shh dónde va a encontrar el archivo que contiene mi clave privada. El archivo puede tener cualquier nombre, útil si utilizamos diferentes claves privadas para diferentes servidores (cosa ahora innecesaria, podemos utilizar la misma de ser posible). La ruta al archivo variará según la distribución y donde se monta el dispositivo que tiene dicho archivo.
Doy por sobre entendido que el servidor remoto debe ser accesible desde Internet, por ello utilicé ese «dominio» falso para subrayar este hecho. Si fuera accesible desde la red local, simplemente se utiliza su IP, como hacíamos hasta ahora…
Consideraciones finales
- En lo posible, imposibilitar el acceso de root por SSH (mejor aún si inhabilitan su login)
- Cambiar el puerto de SSH por cualquier otro disponible
- Utilizar archivos clave SSH y llevar consigo los que poseen la clave privada
- No perder el archivo clave privado, de ocurrir habrá que generar un nuevo par
- Crear un usuario para ingresar por SSH y pertenezca a los sudoers, cuya clave no caduque nunca (y recordar dicha clave) a los efectos de acceder si se perdiera el archivo de clave privada
- No es mala idea darle permisos 400 a los archivos con la clave pública y privada, de modo que sólo el usuario pueda leerlos
Nota Curiosa
La «huella digital» (key fingerprint) y la «imagen al azar» (random art image) que se observan al generar la clave son «útiles» para verificar que el servidor al que se conectan es el correcto.
Varían cuando se reinstala el servidor SSH, o se regenera la clave. Pero es útil la del servidor, siempre que se conozca, para confirmar que llegamos al destino que deseamos y no otro.
La «propia» puede ser útil para verificar la «integridad» de nuestro archivo… Pero para ser honestos, es poco probable que nos detengamos a corroborar tales datos… Hasta que entendamos su relevante importancia en ciertos escenarios en una nota futura.