Y sobre esto último es sobre lo que va este breve y sencillo artículo, ya que es algo que todos deberíamos hacer si tenemos nuestro servidor casero en casa o incluso si usamos un VPS para servir nuestras apps e información.

Los pasos son muy sencillos y conseguiremos que nadie nunca pueda acceder con «usuario/contraseña», ni siquiera nosotros mismos :). Por ello tendremos que tener cuidado y sobre todo probar nuestro acceso previamente con nuestra clave pública generada. Más adelante avisaremos en ese punto crítico para evitar sustos.

Configuración

Clave pública y privada

Lo primero será generar en nuestro equipo una clave pública y otra privada, esta última la copiaremos en nuestro servidor y con ellas podremos acceder desde ese equipo en concreto directamente. Si accedemos con varios equipos a nuestro servidor, tendremos que hacer lo mismo en cada uno de ellos.

Para crear las claves podéis seguir este artículo que escribí hace unos años donde explico todo paso a paso:

Si ya las tenéis creadas, podéis saltaros ese paso y seguir con el siguiente…

Pruebas de conexión

Este punto es el más importante, aunque en el artículo para crear clave pública y privada está explicado, tenemos que tener mucho cuidado y antes de desactivar la posibilidad de conectar por contraseña, tenemos que probar el acceso por clave pública y privada.

La prueba básicamente es lanzar una conexión por SSH a nuestro servidor, desde el equipo en el que tenemos nuestra clave pública, que será reconocida por la clave privada de nuestro servidor y nos dejará acceder. Para ello escribiremos esto desde la línea de comandos de nuestro servidor Windows/Linux:

ssh -i clave_publica.pub usuario@X.X.X.X

En el ejemplo de arriba, hay que tener en cuenta qué:

• -i este es el parámetro usado para decir al comando SSH que usaremos una clave pública para conectar. Siempre tendremos que indicar el fichero que contiene nuestra clave pública para conectar de esta forma.
• clave_publica.pub, es nuestra clave pública para usar, normalmente al crearla se ubica dentro de la carpeta de nuestro usuario seguido de la carpeta .ssh. Por lo que si queremos conectar tendríamos que poner «ssh -i .ssh/clave_publica.pub». Podemos copiar la clave pública en cualquier carpeta que queramos y el nombre del fichero también podemos cambiarla por el que queramos. Solo debemos tener cuidado de ponerlo bien todo a nivel de comando.
• usuario, el nombre de usuario con el que conectaremos a nuestro servidor y que utilizar esas claves pública y privada.
• X.X.X.X, la dirección IP privada o pública que corresponda con nuestro servidor.

Con eso la conexión a nuestro servidor, según pulsemos la tecla «Enter», debería ser directa, sin petición de ninguna contraseña.

IMPORTANTE: Si nos pidiera una contraseña, habría que revisar si estamos usando la clave pública correcta si tenemos varias, si estamos usando el usuario correcto, si la clave privada fue copiada correctamente en el servidor, etc. No desactivar el acceso por contraseña si esto sucede.

Si por el contrario, el acceso es correcto, nos encontraremos ya conectados con nuestro usuario y listos para añadir comandos y trabajar con nuestro servidor.

Deshabilitando acceso

Vamos ahora a deshabilitar el acceso mediante contraseña, esto lo haremos modificando el fichero de confirmación de SSH en nuestro servidor casero.

Lo primero será editar el fichero de configuración con permisos de root. El fichero es el siguiente y lo editaremos con nuestro editor favorito, en mi caso «vi»:

sudo vi /etc/ssh/sshd_config

Buscamos la siguiente línea en nuestro fichero:

#PasswordAuthentication yes

Seguramente se encuentre comentada con una almohadilla al inicio. Por lo que haremos dos cosas:

• Quitar la almohadilla para activarla, y
• Cambiaremos el «yes» por el «no»

La línea quedará así:

PasswordAuthentication no

Ahora salvamos el fichero y tocará reiniciar el servicio de SSH para que se apliquen estos cambios. No será necesario reiniciar y se aplicarán directamente los cambios.

Ejecutamos el siguiente comando para reiniciar:

sudo systemctl restart sshd

o con «Service» si tenemos una distribución linux sin SystemV:

service ssh restart

Y con esto ya estaría todo. Ahora solo quedaría que desconectarais y probar directamente el acceso con clave pública/privada.

Espero que esto os sirva para securizar un poco más vuestro servidor auto alojado

Preguntar, dudas o cuestiones como siempre en los comentarios.

¡Nos vemos por el Fediverso!

Europa se ha debilitado durante años incluso décadas, hemos dejado de construir dejando todo el «suministro» fuera de nuestras fronteras, depender peligrosamente de otros y lo que es pero, sin alternativas.

Pero como decía, Europa ya está en marcha para ofrecer esas alternativas que son tan necesarias y que nos ayudarán a no temer tanto lo que determinados dirigentes puedan o no querer hacer, prohibir, controlar…

Primeros pasos

Uno de los primeros pasos ha sido presentar las DNS europeas para romper definitivamente con algo que hace muy fuerte a compañías fuera de Europa como Google, OpenDNS de Cisco o incluso Cloudflare, que es hurgar en nuestro tráfico, en que buscamos, que nos interesa… en definitiva todo lo que hacemos en internet. Con estas nuevas DNS europeas, ese tráfico no saldrá de Europa, rompiendo esa dependencia que tenemos de ellos.

Junto a eso, tienen un claro sentido de «protección», ya que vienen por defecto con potentes filtrados para frenar el spam, malware e incluso contenido no adecuado para menores. Una opción muy interesante ya de por sí, para aquellas familias que no tengan los conocimientos suficientes para instalar algún bloqueador de este tipo de amenazas, y que les servirá simplemente configurando estas DNS para frenar ese contenido peligroso.

DNS4EU para el público

Estas DNS llegan como dicen en la propia página oficial, como una alternativa en un mercado con un claro monopolio y además para conseguir una libertad, independencia, privacidad y seguridad en Europa.

Para ello, han puesto a disposición del público diferentes «sabores» de DNS para que cada uno decida el nivel de protección que necesita según el caso. En esta página encontraréis toda la información: https://www.joindns4.eu/for-public

Cada persona podrá elegir si no quiere filtrar nada, si quiere que sus peticiones estén protegidas, si quiere evitar anuncios, protección infantil… en total 5 opciones a la hora de resolver que pueden cumplir las expectativas de cualquier usuario europeo.

Aquí abajo las tenéis descritas al igual que en la página oficial que os puse más arriba:

1. Protective Resolution – IP address 86.54.11.1
2. Protective + Child Protection – IP address 86.54.11.12
3. Protective + Ad blocking – IP address 86.54.11.13
4. Protective + Child Protection + Ad blocking – IP address 86.54.11.11
5. Unfiltered Resolution–  IP address 86.54.11.100

También existen las correspondientes opciones para IPv6, DNS over HTTPS o DNS over TLS.

Ahora ya solo os toca elegir que tipo de resolución os gustaría, sin filtrar o un filtrado de protección

Probando las DNS

Al tener hijos mi opción en cuanto a filtrado fue claro, tenía que elegir las más completa: Protective + Child Protection + Ad blocking.

Primero comencé añadiéndolas en mi portátil personal bajo UltramarineOS (basada en Ubuntu) y tengo que decir que el funcionamiento, en cuanto a respuesta y calidad en el filtrado fue realmente buena.

Sin Pi-hole de por medio, el filtrado de páginas maliciosas, de violencia o de contenido pornográfico fue excepcional, bloqueó prácticamente todo incluso sin contar tampoco con un adblocker en el navegador. Si bien alguna dirección se le escapó, es realmente fiable y segura en el filtrado.

Pero como esto es subjetivo, probé el rendimiento y velocidad de respuesta con una de las mejores aplicaciones para ello, como es DNS Benchmark, con la que se puede medir el rendimiento de los servidores DNS de los cuales queráis tener información.
La página donde la podéis descargar si os interesa es esta: https://www.grc.com/dns/benchmark.htm

Mi configuración fue como DNS principal el «todo incluido»: 86.54.11.11 y como secundario el de protección básica: 86.54.11.1.

En la aplicación añadí todos los servidores DNS europeos para comprobar su rendimiento:

Una vez añadidos lancé la prueba (tardó unos cinco minutos) con los siguientes resultados realmente buenos:

Nuestro servidor «todo incluído» europeo quedó en tercer lugar (el primero es la IP de nuestra máquina local, esa no cuenta) solo superado por NTT Data y el servidor europeo con protección + child protection (86.54.11.12). Y quedando por encima de las grandes «ballenas» del mercado.

Eso sí, algunos servidores de DNS4EU quedaron alejados del top como mi DNS secundario (86.54.11.1) por lo que eso me permitió conocer que era mejor configurar como segunda alternativa el segundo servidor más rápido de DNS4EU que es el de protective + children protection.

Así pues finalmente configuré mi Pi-hole con los dos servidores más rápidos:

• 86.54.11.11
• 86.54.11.12

Por último hice algunas pruebas más como un test de filtros básicos desde http://testfiltering.com/test/ que devolvió un OK en todo:

Y luego le «presioné» un poco con una página de tests más avanzada (https://netskopesecuritycheck.com) y no devolvió malos resultados aun cuando solo tenía configuradas esas DNS sin ningún tipo de blocker adicional en ningún lado:

Finalmente así quedó mi Pi-hole configurado, donde mis primeras DNS sobre las europeas y después como «backup» dejé configuradas las de Quad9 que tienen su sede en Suiza, también en Europa.

Conclusión

Este es un primer paso para nuestra independencia y es un gran avance, ya que nos da una libertad y protección que no teníamos, porque protegen nuestra privacidad ya que estas DNS se ciñen a la GDPR y además anonimizan nuestros accesos.

Así pues ya sabéis, cambiar en vuestros dispositivos las DNS en cuanto podáis

Página Oficial: DNS4EU | Join the European Safe digital space