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

Buscando un gestor de credenciales que tuviera las siguientes dos premisas, que fuese Open Source primeramente y segundo que se pudiera utilizar en cualquier plataforma ya fuese móvil, windows, linux, macos, etc di de cara con Buttercup un gestor que cumple con ellas y que además tiene una extensión compatible con prácticamente todos los navegadores. Se puede decir que esta app es un todoterreno.

Llevo utilizándola ya bastante tiempo y aunque en sus versiones más iniciales tuvo algún que otro problema, ahora mismo se encuentra en un estado muy estable y prácticamente sin errores. De todas maneras, es uno de los proyectos de Github más interesantes actualmente. Así pues, si os interesáis en probadla, estáis de suerte porque os enseñaré el truquito para poder abrir un fichero de claves que tengáis compartido desde Google Drive, pues en la mayoría de distros falla. Allá vamos.

Instalación y configuración

Lo primero será descargar la versión para nuestro sistema desde la página oficial https://buttercup.pw según el sistema en el que estemos. Esta pequeña guía será para hacerlo en GNU Linux pero si tenéis MS Windows valdrá igual. Además tenéis como comenté para Android e iOS también desde sus páginas oficiales.

Seleccionamos la opción de Linux (AppImage) y comenzará a descargar el paquete en nuestro equipo. Abajo os he marcado donde podréis ver la última versión disponible, en este caso las 2.27.0.

Ahora instalemos la aplicación. Abrimos una consola y lo que haremos será:

• Ubicar el ejecutable en la carpeta que queramos,
• Le daremos permisos de ejecución, y
• Utilizaremos un fichero ubicado en GDrive con nuestros credenciales.

Tendremos el ejecutable en nuestra carpeta de «Descargas» voy a moverlo a otra dentro de mi «Home» de aplicaciones, llamada «apps»:

Le damos permisos de ejecución para poder arrancar la aplicación con nuestro usuario, para ello utilizaremos el comando chmod de la siguiente manera:

chmod +x Buttercup-linux-xxxxxx.AppImage

Lo podéis ver en esta imagen de abajo, como los permisos de ejecución quedan habilitados. En la mayoría de sistemas cuando hagáis eso, el color del fichero cambiar a a color verde para identificarlo como fichero «ejecutable»:

Toca arrancarlo para ver si funciona correctamente:

Esto comenzará el arranque de la app y lo primero que nos preguntará por una contraseña para un nuevo «keyring», llavero en español, que será nuestra contraseña maestra si únicamente vamos a utilizar un fichero en local. Por ello si esto es así, la contraseña debe ser segura, larga y con caracteres alfanuméricos… en otras palabras «la leche de difícil para descifrar» :D. Cuando sepamos cual, la añadimos:

Y con esto ya se nos abrirá la aplicación en nuestro escritorio:

Comprobada que la aplicación funciona, la volvemos a cerrar.

Lanzador de ficheros appimage

Las aplicaciones .appimage en muchas de las distribuciones requieren de un «punto de entrada» para poder integrarlas en el sistema y así poder abrirlas directamente con dicha aplicación. Para que lo entendáis, es como ocurre con otras aplicaciones por ejemplo con los vídeos o fotos de nuestro equipo, cuando pulsáis en ellas automáticamente se nos abre el visor de vídeos y fotos que tengamos configurados por defecto, pues eso mismo es necesario para cuando queramos abrir un fichero .bcup de Buttercup, necesitaréis que sea abierto por su aplicación directamente.

Para ello descargaremos un launcher para aplicaciones .appimage desde la siguiente dirección de Github:

• https://github.com/TheAssassin/AppImageLauncher/releases

Buscaremos la descarga correspondiente a nuestro sistema, por mi parte como lo instalaré en mi Ultramarine OS basado en Fedora descargaré la versión .rpm.
Lo haremos directamente desde la terminal utilizando el comando wget seguido de la URL con el fichero correspondiente a nuestro OS:

Instalamos el paquete .rpm para mi sistema (Necesitaréis permisos de root):

Nos dará un warning indicando que habrá una recarga de uno de nuestro demonios que están corriendo y listo. Ya estará instalado el launcher.
Vamos a comprobarlo ya que tendremos que hacer la integración con nuestro sistema.

Ejecutamos la aplicación de Buttercup como hemos hecho anteriormente:

Nos saldrá una ventana nueva en la que nos indica si queremos integrar AppImageLauncher con nuestro sistema o solo una vez, elegiremos la integración para siempre ya que es lo que queremos, elegimos el botón de la izquierda:

Si todo ha ido bien, nos abrirá la aplicación en la pantalla y la aplicación la tendremos ya añadida a todas las aplicaciones de nuestro sistema, con lo que será accesible desde el menú de nuestro entorno de escritorio (Budgie, Gnome, KDE…).

Nuestro vault en Google Drive

Ahora vamos a configurar un nuevo Vault. Con el nombre de Vault conocemos el fichero que alojará todas nuestras contraseñas y que será accesible mediante nuestra contraseña maestra que añadiremos una vez que lo creemos. Esa contraseña tendremos que guardarla bien en nuestro cerebro ya que no será recuperable.

Pulsaremos en + Add Vault y entre las opciones que tenemos, elegiremos la correspondiente a Google Drive que es la que mostraremos en esta guía. Si quisiéramos Dropbox, WebDav o incluso un fichero localmente en nuestro equipo podríamos elegir las otras opciones disponibles:

Nos saldrá un mensaje ahora indicando que para utilizar esta funcionalidad tendremos que otorgar permisos a la aplicación para acceder a nuestra cuenta de GDrive o de lo contrario no se podrá utilizar. Vamos a ello, pulsamos el botón de Authenticate:

Añadimos nuestra cuenta de gmail y pulsamos en «Next»:

Seguido de nuestra contraseña y pulsamos en «Next»:

Nos advierte que compartiremos algunos de nuestros datos con la aplicación de Buttercup, le damos a «Continuar»:

Y por último tendremos que darle permisos a cuatro servicios para que la aplicación puede acceder a nuestro fichero de contraseñas que crearemos después:

Ahora, por primera vez, nos dirá que si los enlaces de buttercup (.bcup) queréis que siempre se abran con la aplicación. Marcaremos la casilla para que se permita siempre y le daremos a «Open Link».

Se nos abrirá la aplicación y seguiremos los pasos que quedan para enlazar GDrive con nuestra app, primero creamos nuestro fichero donde alojaremos nuestras contraseñas:

Le damos el nombre que queramos añadiendo la extensión .bcup y pulsamos el botón de «Set Vault Target» cuando lo tengamos:

Ahora ya tenemos enlazada la app con nuestro fichero de contraseñas en GDrive. Señalamos ese fichero y le damos a «Next»:

Ahora viene una parte MUY IMPORTANTE y es configurar nuestra contraseña maestra, elegid una buena contraseña y que NO se os olvide jamás pues es la que abrirá el vault con todos los accesos que hayáis añadido:

Hecho esto ya tendréis totalmente configurada la aplicación con vuestro fichero en GDrive. Solo quedará que creéis carpetas, registros de password y empezar a usarlo.

Os dejo una imagen con mi vault para que veáis como quedaría más o menos:

Ya solo me queda deciros que lo probéis y si lo hacéis que me digáis que os parece y sobre todo si queréis saber más acerca de ello, como sería cómo enlazador con Dropbox o mediante WebDav localmente, cómo exportar/importar desde otras apps del mismo estilo, configurar desde app de Android o iOS, etc.

Espero que os sirva de ayuda.

¡Nos vemos por el Fediverso!

El servidor proxy inverso siempre se sitúa por delante de los servidores/servicios web que tengamos en el servidor y es el que se encargará de reenviar las solicitudes que reciba hacía los servicios alojados. Es por ello, que es el servicio que tenemos que configurar primeramente es este.

Para instalar este proxy necesitaremos de la última versión LTS de NodeJS, la cual descargaremos desde un repositorio. Por defecto, en Debian 12 viene la versión 18 que serviría, pero siempre me gusta tener actualizada la aplicación a la última versión LTS (Long Term Support) que exista, en este caso la versión 20.

Antes de nada y como práctica habitual, primero haremos un update y upgrade para dejar el sistema actualizado hasta ese mismo momento. Lanzamos los comandos pertinentes:

sudo apt update && sudo apt upgrade -y

Después ya podemos ir a la página del repositorio llamado NodeSource de NodeJS (https://deb.nodesource.com) desde donde podremos descargar e instalar la última versión LTS de esta herramienta. En su página veremos lo sencillo que es, básicamente tendremos que copiar/pegar dos líneas.

Pero antes de lanzar estas dos líneas, habrá que instalar el comando curl ya que por defecto no viene instalado por Debian.
Lanzamos la instalación:

sudo apt install curl

curl -fsSL https://deb.nodesource.com/setup_20.x | sudo bash -
sudo apt-get install -y nodejs

Si todo ha ido bien, podemos ver que ya lo tenemos instalado:

jmdlr@debian:~$ curl --version
curl 7.88.1 (x86_64-pc-linux-gnu) libcurl/7.88.1 OpenSSL/3.0.11 zlib/1.2.13 brotli/1.0.9 zstd/1.5.4 libidn2/2.3.3 libpsl/0.21.2 (+libidn2/2.3.3) libssh2/1.10.0 nghttp2/1.52.0 librtmp/2.3 OpenLDAP/2.5.13
Release-Date: 2023-02-20, security patched: 7.88.1-10+deb12u5
Protocols: dict file ftp ftps gopher gophers http https imap imaps ldap ldaps mqtt pop3 pop3s rtmp rtsp scp sftp smb smbs smtp smtps telnet tftp
Features: alt-svc AsynchDNS brotli GSS-API HSTS HTTP2 HTTPS-proxy IDN IPv6 Kerberos Largefile libz NTLM NTLM_WB PSL SPNEGO SSL threadsafe TLS-SRP UnixSockets zstd

Con esto ya estaríamos listos y podemos lanzar las dos líneas que ponían en la página del repositorio:

curl -fsSL https://deb.nodesource.com/setup_20.x | sudo bash -
sudo apt-get install -y nodejs

Terminada la instalación, toca comprobar que la versión instalada de NodeJS es la que queremos, en este caso la 20 LTS.
Ejecutamos el siguiente comando para visualizar la versión:

jmdlr@debian:~$ node -v
v20.13.1

¡Bien hecho! Ahora ya solo toca instalar el proxy, para ello vamos a la página oficial de GitHub de NPM para ver la última versión disponible he instalarla.

• https://github.com/NginxProxyManager/nginx-proxy-manager

Vamos a seguir exactamente los pasos que se indican ahí, que de manera resumida son las siguientes.

Creamos un fichero docker-compose.yml:

vi docker-compose.yml

Añadimos el siguiente contenido:

version: '3.8'
services:
  app:
    image: 'docker.io/jc21/nginx-proxy-manager:latest'
    restart: unless-stopped
    ports:
      - '80:80'
      - '81:81'
      - '443:443'
    volumes:
      - ./data:/data
      - ./letsencrypt:/etc/letsencrypt

Estamos indicando en el fichero qué:

• Usaremos la última imagen disponible que exista del NPM,
• Abriremos los puertos 80, 443 y 81 para el dashboard de administración de la app, y
• Se crearán las siguientes carpetas de «data» y «letsencrypt».

Salvamos el fichero (:wq!) y lo ejecutamos:

docker compose up -d

Esto tardará un ratillo entre que descargar la imagen, configura, etc. Al final tendrá que indicarnos con checks de color verde, que todo ha ido bien.
Para confirmarlo podemos ver en qué estado está la aplicación dentro de docker, para ello ejecutamos lo siguiente:

docker ps

Y tendría que devolvernos que el contenedor de la aplicación está corriendo como podremos ver en la columna de «Status», que dirá el tiempo que lleva levantado:

jmdlr@debian:~$ docker ps
CONTAINER ID   IMAGE                             COMMAND   CREATED          STATUS          PORTS                                                                                  NAMES
016fdef7c34a   jc21/nginx-proxy-manager:latest   "/init"   57 seconds ago   Up 55 seconds   0.0.0.0:80-81->80-81/tcp, :::80-81->80-81/tcp, 0.0.0.0:443->443/tcp, :::443->443/tcp   jmdlr-app-1

Si esto es así, el servicio estará levantado, probemos directamente lo que nos dice el puerto 80.
Abrimos un navegador en nuestro equipo y atacamos a la IP de nuestro servidor en mi caso será la IP 192.168.1.12:

Ahora vamos a ir a la página de administración de NPM que por defecto se configura en el puerto 81 y nos devolverá esta ventana de «login»:

Para acceder, como se indica en la página oficial tendremos que utilizar estas credenciales de abajo, que posteriormente nos obligarán a cambiar la primera vez que accedamos, al igual que el nombre, usuario y dirección de correo electrónico.

• Usuario: admin@example.com
• Contraseña: changeme

Añadimos la información que queramos poner y daremos al botón de «Save». Y ya estaremos en la página principal desde la que gestionaremos los diferentes apartados de nuestro proxy.

Y hasta aquí toda la instalación de nuestro proxy, seguiremos en próximos artículos con la instalación de los diferentes servicios que queramos tener disponibles en nuestro servidor y veremos como debemos configurar NPM para que las peticiones sean redireccionadas según al servicio que se quiera acceder.

¡Nos vemos por el Fediverso!

La situación es alarmante si te quedas a pensar en ello por un momento, por ese motivo siempre habrá que intentar poner muros, defensas, aduanas ante ello, para tener más control sobre nuestra información. Y es por ello, que empiezo este pequeño proyecto de self-hosting desde mi blog, por que si no podemos evitar que nuestra información personal se filtre y alguna la tengan por defecto (nuestro correo electrónico), si al menos, mantengamos nuestros datos, ubicados en nuestra misma casa con nuestro hardware, de manera segura y sin muchas parafernalias.

Esto solo pretende ser una guía de cómo hacerlo, no será la verdad verdadera. Una vez sepáis como funciona esto del «self-hosting» o «self-hosted» si queréis añadir más dificultad, más componentes, más servicios, diferentes vlans, etc. Eso correrá de vuestra parte. Por mi lado, aquí explicaré una configuración básica con lo que empezar y con servicios de «más uso».

¿Qué vamos a montar?

Una mini-arquitectura en nuestra ubicación local para tener diferentes servicios, que ahora tendréis externalizados prácticamente en su totalidad o a lo mejor algunos de ellos y de esta manera tenerlos en vuestra propia vivienda, local, etc. Mostraré la instalación de los diferentes componentes y servicios utilizando apps de Software libre paso a paso en su mayoría (tengo Emby aun por aquí rondando). Y añadiremos la seguridad que sea necesaria para evitar cualquier problema.

La intención, explicada de manera breve y rápida, es montar un pequeño servidor con un proxy inverso y detrás de él unos cuantos servicios que pueden ser más o menos interesantes para vuestro uso diario. Estos servicios que he pensado (pueden ser modificados durante las diferentes entradas en el blog) que podrían ser interesantes para instalar en nuestro servidor serían los siguientes:

• Un buscador como puede ser SearXNG para realizar búsquedas seguras,
• Un agregador de enlaces rss para estar informados de noticias, blogs, que nos interesen como puede ser FreshRSS,
• Una plataforma de mensajería para comunicarnos de manera segura como SimpleX,
• Una plataforma de blogs para escribir y compartir nuestras cosas, bien con WordPress, Ghost o Bludit,
• Una pequeña nube de alojamiento de ficheros con otras opciones como puede ser FileBrowser, Nextcloud, etc,
• Una aplicación de monitorización para controlar nuestro sistemas como Uptime Kuma, Umami, etc,
• Un protector DNS para quitar basura en nuestra red local como Pi-hole,
• Un centro multimedia para ver nuestro contenido privado de vídeos, fotos… que podemos hacer con Emby o Jellyfin, y
• Muchas más cosas si hay interés en montarlo.

¿Qué necesitamos?

Pues varias cosas, pero en resumen los requisitos mínimos serían:

• Red eléctrica (¿obvio no?)
• Conexión a internet, preferentemente fibra aunque si tenéis ADSL… ¡pues no queda otra!
• Una RaspberryPI 3B o versión superior o bien algún portátil, PC viejo, etc. Recomiendo una Raspberry o algo similar por el consumo de red eléctrica.
• Un MiniPC o NUC, si vamos a querer añadir bastantes servicios, lo mejor en cuanto a rendimiento, coste de luz, etc. sin duda necesitamos este hardware. También podría servir una RaspberryPI de las últimas o una OrangePi, pero sigo opinando que por precio/rendimiento un minipc es mejor inversión. Pero para gustos los colores. Como otra opción también sería tener varias Raspberry/OrangePi y distribuir los servicios por ellas… la arquitectura puede ser flexible como veis.

Por mi parte usaré lo siguiente de lo expuesto anteriormente: Red eléctrica, conexión vía fibra, RaspberryPi 3B+ y Mini-PC (GK41).

Servicio a servicio

Comenzaré en breve a publicar los diferentes posts sobre este proyecto e iré pasito a pasito pero sin prisa, aunque tampoco sin pausa. La idea ir haciendo todo esto a la vez que voy modificando toda mi red interna de casa, que no está como quisiera y que quiero dejarla mejor de lo que está. Aquí os dejo el artículo que publiqué del estado actual de mi red: http://mindeka.duckdns.org/2020/05/23/red-interna-de-casa/.

Así que aprovechando el cambio que quiero hacer de todo, utilizaré mi blog para ir publicando todo y si alguien más quiere dar el salto y auto-alojarse sus servicios pueda hacerlo. Dejo aquí el dibujo final que hice de cómo quedará mi red interna algún día de estos, únicamente exponiendo dos a internet y dentro tener una mini-infraestructura ser microservicios para dar soporte a mi familia y a mi mismo.

Y poco más gente, a futuro ya hablaremos de ciertos «pros» y «contras» de tener esto auto-alojado localmente para que podáis decidir si es buena idea para vosotros o no según bastantes factores.

¡Nos vemos por el Fediverso!

Hoy trataremos como dice el artículo, como acceder a nuestro servidor vía ssh sin contraseña pero sí con nuestra propia clave pública/privada.

Creando nuestra clave

La clave se generará en nuestro ordenador de sobremesa, portátil… en definitiva desde el cual accederemos al servidor X.

Generamos nuestra clave:

$ ssh-keygen -b 4096

Con el parámetro -b indicamos que queremos que sea una clave robusta de 4096 bits. Con 2048 bits sería suficiente, pero me gusta ser un tipo duro
Durante la generación nos hará una serie de preguntas que tendremos que responder si queremos cambiar algo o bien dejar por defecto:

jmdlr@casa:~$ ssh-keygen -b 4096
Generating public/private rsa key pair.
Enter file in which to save the key (/home/jmdlr/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/jmdlr/.ssh/id_rsa.
Your public key has been saved in /home/jmdlr/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:e1S4R43AcFqR3NADcOtS4wDth2RYAojBQp3E28WUGIQ jmdlr@casa
The key's randomart image is:
+---[RSA 4096]----+
|+++o=+B===OB     |
|o..E ..*+=+++o   |
|.   o .+o.= +..  |
|   . .  o=.=     |
|        S.= .    |
|         + .     |
|        . .      |
|         .       |
|                 |
+----[SHA256]-----+

Breve explicación de cada pregunta:

• Enter file in which to save the key (/home/jmdlr/.ssh/id_rsa): Ubicación donde se almacenará nuestra clave tanto privada como pública. Se puede modificar pero no es necesario.
• Enter passphrase (empty for no passphrase): Se puede añadir una frase por si quieres fortalecer la seguridad de tu clave. Por experiencia dejadla en blanco, terminaréis por olvidarla si no la apuntáis y tendréis que generar una nueva. El resto de líneas solo confirman que se han creado las claves con tu figerprint asociado. Ya estaría lista.

Consultando nuestra clave pública

Ahora ya podremos ver nuestras claves generadas, si no hemos cambiado la ruta por defecto estará en una carpeta oculta dentro de la «home» de nuestro usuario llamada .ssh/

Ahora tendríamos que ir a nuestra «home» en mi caso es /home/jmdlr y luego acceder a la carpeta oculta .ssh:

$ cd /home/jmdlr/
$ cd .ssh/
$ ls -lrth
total 8.0K
-rw------- 1 jmdlr jmdlr 3.2K Mar 30 00:42 id_rsa
-rw-r--r-- 1 jmdlr jmdlr  736 Mar 30 00:42 id_rsa.pub

Veremos que tenemos dos ficheros que tienen por nombre id_rsa. Una de ellas es la clave privada (id_rsa) la cual NO tendremos que compartir y luego la clave pública (id_rsa.pub) que es la que subiremos a nuestro servidor o al servidor que deseemos acceder sin que nos solicite password. Echamos un vistazo a la clave pública:

$ cat id_rsa.pub
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQDDGnQn+2Jld5Y/822sLmZc/1PC0+gm3ORtbRPEUvzuqMIMOVg2ImZPApj/d7+K57MP
y7pQDn/iwi3QkLzpf/tL9LXF2+FouzVsSeZgR1dd7+3QGTMPch+5hXZxuims+zZOLFuXqXzhb00TSMbH5yVBH1gv+qCZj7N/DvRgok+2
Fae1I+Fr0/7ALIaLfFEo5CYfrUNyfuD0ZpJ9GIrv6+sBWbCOomzuw5SMIccbX4VQ+DLmEoMwl3A3GQf3yNrAtjjolPm1zJ0YAd+Kr5UW
REugxTgLslnMHFVozPn5byuj2fT4dQPiB0Zj/mzQf+BWGaT+lI3P/P08mG0gdpD39MUiKGjh0XYbQQh731cnMJK1gTzphPyinROv4S/P
j1HFhSEAbsZJP9l/ZyVi1qupTOFocWEQf0o4yNsVpogDpUQJwEyG5ftQDsmjbHD5EQRMFXktnItdSqhbTVL+qSiB96Jd66CV9+bklUQb
p9w3pT0beZDrKQdPKmrlRYS2MeZB1z5kMnDTm/C1fSDHAuqYAxCyZTBc3ncBpzW7AnWczUdk0zIiToGVs8wE16suGWqlZA2gGLIkY3Ld
vAkzgm9HBIosgZVEPABN4nbMAqv/NqXJd2/e6cFICllX8YhyBcYL9OfwFPK6OUxQg0AKk/rJwSO6aGxDOIHVY16+DvwuQRx1SQ==jmdl
r@casa

Ese texto es lo que tenemos que copiar en todos los servidores remotos a los que queramos conectar vía ssh, pero para hacerlo más fácil, existe un comando que nos ayudará a copiarlo.

Copiando la clave pública al servidor

Simplemente usaremos el siguiente comando desde la ruta donde tenemos nuestra claves.

$ cd /home/jmdlr/.ssh
$ ssh-copy-id -i id_rsa.pub usuario@IP_servidor_remoto

Donde aparece usuario tendremos que poner nuestro nombre de usuario que utilizamos para acceder al servidor y donde aparece IP_servidor_remoto la dirección IP o el registro DNS que nos de acceso al servidor donde queremos añadir nuestra clave pública. En mi ejemplo, accediendo con mi usuario «jmdlr» sería así:

$ cd /home/jmdlr/.ssh
$ ssh-copy-id -i id_rsa.pub jmdlr@10.5.1.5

Y si todo va bien me diría lo siguiente hasta preguntarme cual es mi password del usuario para acceder por primera vez:

/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "id_rsa.pub"
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys

jmdlr@10.5.1.5's password:

Number of key(s) added: 1

Now try logging into the machine, with:   "ssh 'jmdlrk@10.5.1.5'"
and check to make sure that only the key(s) you wanted were added.

En el paso que solicita el «password» tendremos que añadirlo y para la próxima vez que queramos acceder tendremos que hacer lo que indica más abajo, simplemente teclearemos ssh jmdlr@10.5.1.5 y estaremos dentro sin solicitarnos contraseña alguna.

Espero que os haya sido fácil de seguir, cualquier cosilla preguntadme a través de Mastodon/Firefish o Bluesky:

• Mastodon
• Bluesky