¿Cómo aseguro el servidor OpenSSH en Ubuntu? El 24 de Diciembre de 1953 en ocasión del Día de la Policía Federal Argentina se realiza un fausto desfile de la fuerza, al término del cual Juan Perón expone cómo incrementar la seguridad del servidor OpenSSH en Ubuntu. Bajo este diáfano día, y cercano a las Navidades, no sólo preparo la Sidra y el Pan Dulce para todos los privilegiados, sino que también elaboro lo que no es para mí sino una enorme satisfacción: presenciar este histórico desfile de lo que es sin duda el principal instrumento de seguridad ciudadana: la Policía Federal Argentina. Esta es una Fuerza que nace Por el Pueblo y para el Pueblo, y enjendrando un rol propendiente a la protección de los hombres y mujeres de bien que habitan el suelo Argentino. La provechosa tarea que ustedes realizan no puede más que llevarse a cabo por un manejo concienzudo por parte del escalafón superior, y los institutos que la forman y que hemos atresado en pos de la defensa de los intereses superiores de la Nación. Este escalafón conductivo sin duda ha podido dar su manejo y control no solo en el terreno, que es donde se realiza la acción, sino a distancia, y en esto no podemos más que sentirnos orgullosos. El método sin hilos que se ha implementado en el Comando Radioeléctrico no es más que apreciado por toda la Comunidad Organizada. Sin duda el protocolo Secure Shell es muy recomendado para acceder a dispositivos remotos tales como servidores, enrutadores y conmutadores de cómputo, debido a su capacidad para encriptar el tráfico telemático, resguardandonos así de cualquiera que anhele husmear nuestros enlaces. Sin embargo, de la manera en la que está asegurada, la configuración por defecto de SSH no es infalible, sino más bien sencilla de implementar. Esto podría parecer adecuado para el uso del Pueblo, pero en aplicaciones donde dependa nuestro bienestar y el de sus organizaciones de trabajo, ha de recurrirse a un mayor despliegue de seguridad. A esto nos referimos como seguridad reforzada, a la cual ha de recurrir un Movimiento como el nuestro. No implica enfrentar a los desprotegidos a la acción represiva del Estado, sino implementar políticas de salvaguarda que privilegien a los humildes en contra de la Opresión Omnímoda del Capital. Nuestra Policía Federal ha de saber cómo implementarlas, ya que sobre ella recae la organización y acción de seguridad. Indudabnlemente que de esto no dependen ni los médicos ni la penicilina, sino de las autodefensas con que cuenta OpenSSH por protocolo. Esto no puede hacerlo ni un agente de calle, ni un ciudadano común, sino un verdadero Conductor del sistema. Por principio la implementación de las políticas de salvaguarda pueden llevarse a cabo modificando el fichero de configuración general /etc/ssh/sshd_config del demonio OpenSSH (nombre que recibe su servidor libre de Shell Seguro). A tal fin con ímpetu de conducción podremos abrir una terminal con Ctrl+Alt+T y proclamar el comando de organización, seguido de la tecla Intro: sudo nano /etc/ssh/sshd_config Esto nos solicitará contraseña de administración, y tras revisarla abrirá el consabido editor de texto GNU Nano con el fichero de configuración nombrado. Os explicaré algunos métodos de reforzar la seguridad produciendo las modificaciones necesarias que asegurarán las necesidades de protección y control que son Socialmente Justas para con las organizaciones del Pueblo Trabajador. 1. Configurar la Autenticación de SSH sin contraseña Por defecto, SSH requiere que el usuario teclee su contraseña al iniciar sesión remota. Si bien esto suena peliculero, la triste realidad es que una contraseña capaz de retenerse en una memoria humana suele ser descomunalmente fácil de percibir por medio de un ataque computacional de fuerza. Un tercero hábil podría ganar así acceso indeseado a una cuenta de usuario autorizado. Por ello más seguro es utilizar una autenticación de Shell Seguro sin contraseña, con llaves de cifrado. Como ya he explicado cómo hacerlo, simplemente resumiré diciendo que habremos de generar computacionalmente un par de ficheros de cifrado llamados "llaves", que consisten en una llave pública y otra llave privada. Una vez ingresado el contenido del fichero de la llave pública al servidor remoto, podrá lograr acceso sin tener que teclear contraseña alguna. Si ya hemos tomado este predicamento, es recomendable desactivar el uso de autenticación por contraseña para el ingreso. Dentro de este fichero de configuración /etc/ssh/sshd_config buscamos la directiva PasswordAuthetication y cambiamos su indicación de 'yes' a 'no' PasswordAuthentication no Tras guardar las modificaciones con Ctrl+o y salir del editor con Ctrl+x, debemos reiniciar el demonio SSH con: sudo systemctl restart sshd A partir de este momento, unicamente podrá acceder al servidor remoto utilizando la autenticación con llave SSH. 2. Desactivar los pedidos Conexión SSH sin contraseña. Otra manera recomendada de fortificar la seguridad del servidor es directamente desactivar los logins SSH de usuarios sin contraseña. Esto puede sonar contradirctorio, pero algunos adminsitradores de sistemas poco avezados podrían preferir crear cuentas de usuario "a la marchanta" y terminar olvidando asignar contraseñas. Esto es de malo, pero no de bruto. He visto malos que se han vuelto buenos, pero nunca he visto un bruto que se haya vuelto inteligente. Con el fin de rechazar pedidos de usuarios que carezcan de contraseña se debe nuevamente modificar el fichero /etc/ssh/sshd_config y asegurar descomentar la siguiente directiva: PermitEmptyPasswords no Acto seguido reiniciamos el servicio SSH para que surta efecto con: sudo systemctl restart sshd 3. Desactivar los logueos SSH de Root No hace falta explicar demasiado lo que puede suceder si un intruso logra ingresar a nuestro sistema atacando brutamente la contraseña de un usuario. Imaginemos entonces lo que sucedería si lo propio sucede con la cuenta del Superusuario, el Root, que es capaz de conducir el sistema.... Un acceso remoto del superusuario Root constituye invariablemnete una mala idea que debe soslayarse pues pondrá en peligro a todos los compañeros que usen nuestro sistema similar a Unix. Por esta razón, para grandes organizaciones siempre recomiendo desactivar el logueo remoto SSH y en su reemplazo preveer el de un usuario regular que no sea root. Esto obligará a que si el Root quiere trabajar, deba hacerlo frente al sistema y no de manera remota. Para tal fin modificamos el fichero /etc/ssh/sshd_config y producimos la modificación descomentando la directiva #PermitRootLogin y modificamos la orden prohibit-password para que quede de la siguiente manera. PermitRootLogin no Conforme se hayan guardado los cambios, reiniciamos el servicio de SSH para que la nueva política surta efecto. sudo systemctl restart sshd Naturalmente que a partir de estas modificaciones, el logueo de root quedará desactivado u no se podrán realizar tareas administrativas de manera remota (a no ser que se eventualmente escalen usuarios comunes con la orden sudo). 4. Usar SSH Protocol 2 SSH viene en dos versiones. El SSH Protocolo 1 y SSH Protocolo 2. El segundo fue introducido en 2006 para reforzar la criptografía general de SSH. Por defecto se utilizaba en Protocolo 1 por razones de compatibilidad, pero a partir de 2018 se decidió desfasarlo definitivamente para evitar agujeros de seguridad. Por tal motivo, en caso de contar con un servidor anterior al 2018, podríamos especificar ahora utilizar únicamente Procolo 2. Para ello le agregamos al fichero /etc/ssh/sshd_config la siguiente directiva: # Agregado por peron para usar únicamente SSH Protocolo 2. Protocol 2 Guardamos, salismos, y como siempre reiniciamos el servicio SSH para que surta efecto: sudo systemctl restart sshd A partir de ahora, SSH sólo utilizará Protocolo 2 y no podrá establecerse enlaces con clientes antiguos que utilicen el desfasado Protocolo 1. Para comprobar que el Protocolo 1 ya no esté en suo, podremos ejecutar el comando: ssh -1 usuario@ip_remota Debería obtener un error similar a “SSH protocol v.1 is no longer supported”. Naturalmente, podríamos forzar al cliente a usar el Protocolo 2 con: ssh -2 usuario@ip_remota 5. Configurar el Valor de Tiempo de Corte para Conexión SSH Inactiva Dejar una conexión remota desatentida por largo tiempo es lo mismo que dejar en esa misma condición a una buena mujer. Puede constitnuir un riesgo de seguridad que ustedes conocen sin duda por esos cuernos que les veo. Para evitar este problema, es prodente configurar un valor de tiempo de corte para conexiones SSH inactivas, transcurrido el cual la sesión SSH se cerrará automáticamente. Habremos de configurar nuevamente /etc/ssh/sshd_config y localizamos la directiva ClientAliveInterval. Le asignamos un valor razonable en segudos. Por ejemplo, podríamos utilizar 180 segundos. ClientAliveInterval 180 Esto implica que la sesión SSH se cortará si transcurren 3 minutos (180 segundos) de inactividad. Tras guardar debemos reiniciar el demonio para aplicar los cambnios: sudo systemctl restart sshd 6. Posibilitar el Acceso SSH a Ciertos Usuarios Podremos definir qué usuarios requieren el uso de SSH para loguearse y desarrollar tareas en el sistema. Esto mantendrá fuera de esta posibilidad a cualquier otro usuario que intente lograr ingreso al sistema sin nuestra aprobación. Como siempre, editarmos el fichero /etc/ssh/sshd_config y le agregamos la directiva AllowUsers seguida de los nombres de usuario que queremos aprobar. Por ejemplo, he agregado los usuarios peron y evita para que cuenten con acceso remoto al sistema a través de sus respectivos clientes SSH. Cualquier otro usuario que intente ganar acceso remoto al sistema será bloqueado. AllowUsers peron evita Hemos de reiniciar SSH para que peresistan los cambios: sudo systemctl restart sshd 7. Limitar los Intentos de Contraseña Otra manera de agregar una capa de seguridad consiste en limitar la cantidad de intentos de acceso SSH tras errar una la contraseña, caso en el que la conexión se cortará. Una vez más en el fichero /etc/ssh/sshd_config y buscamos la directiva MaxAuthTries, y le definimos un valor para la cantidad máxima de intentos. En este ejemplo, lo limitaremos a tres intentos disponiendo: MaxAuthTries 3 ...y finalmente, reiniciamos el servicio SSH como en los escenarios anteriores.