Cómo utilizar el servicio Secrets Manager para guardar las claves privadas de SSH

Para guardar la clave privada en el servicio Secrets Manager como un secreto en modo texto sin formato, sigue estos pasos

Supongamos que la clave privada es la siguiente:

$ cat test-ssh-keymanager.pem
-----BEGIN OPENSSH PRIVATE KEY-----
b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAAAMwAAAAtz
c2gtZWQyNTUxOQAAACA1pQ/Y0cEWg9g5hFaC2rQwekb6Vq4XQQnIZ97FmevtUgAA
AIjWYCtU1mArVAAAAAtzc2gtZWQyNTUxOQAAACA1pQ/Y0cEWg9g5hFaC2rQwekb6
Vq4XQQnIZ97FmevtUgAAAEAwUQIBATAFBgMrZXAEIgQgJRY8kmxcE/QPgCTmOxdp
RDWlD9jRwRaD2DmEVoLatDB6RvpWrhdBCchn3sWZ6+1SAAAAAAECAwQF
-----END OPENSSH PRIVATE KEY-----

Y lo hemos guardado en un secreto llamado "keyssh". Con el siguiente comando, podemos recuperar su valor y mostrarlo en pantalla:

$ aws secretsmanager get-secret-value --secret-id keyssh \
--region eu-west-1 | jq --raw-output '.SecretString'
-----BEGIN OPENSSH PRIVATE KEY-----
b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAAAMwAAAAtz
c2gtZWQyNTUxOQAAACA1pQ/Y0cEWg9g5hFaC2rQwekb6Vq4XQQnIZ97FmevtUgAA
AIjWYCtU1mArVAAAAAtzc2gtZWQyNTUxOQAAACA1pQ/Y0cEWg9g5hFaC2rQwekb6
Vq4XQQnIZ97FmevtUgAAAEAwUQIBATAFBgMrZXAEIgQgJRY8kmxcE/QPgCTmOxdp
RDWlD9jRwRaD2DmEVoLatDB6RvpWrhdBCchn3sWZ6+1SAAAAAAECAwQF
-----END OPENSSH PRIVATE KEY-----

Si ejecutamos lo siguiente, recuperamos el valor y lo guardamos en una variable de entorno:

$ secret_key=$(aws secretsmanager get-secret-value --secret-id keyssh \
--region eu-west-1 | jq --raw-output '.SecretString')

Luego, podemos agregarla al agente de SSH (si no está activo, ejecutamos 'eval $(ssh-agent)'), donde $secret_key es la variable de entorno donde hemos guardado la clave:

$ ssh-add - <<< ${secret_key}

Listamos las claves para comprobar:

$ ssh-add -l

Y finalmente, podemos hacer SSH al servidor. El SSH se encargará de leer la clave desde el ssh-agent:

$ ssh ec2-user@A.BB.CCC.DDDD

Cluster de Kubernetes de andar por casa

Uno de los problemas que he visto que voy a tener con mi cluster de kubernetes que tengo formado por tres maquinas virtuales (un master mas dos nodos worker) es el almacenamiento persistente. Si desplegaba algún contenedor de tipo statefulset, tenia el problema de que los datos del mismo eran solo accesibles si el pod corría en el nodo donde se creo por primera vez, ya otro nodo no podrá acceder al almacenamiento del primer nodo.

Pensando sobre ello y no buscando complicarme la vida en exceso, la solución viene dada por levantar otra maquina virtual que ofrezca el servicio NFS y que los nodos del cluster de kubernetes monten ese recurso NFS. En el cluster de kubernetes hay que desplegar un PVC para que utilice el recurso NFS compartido. De esa forma, todos los nodos del cluster podrán ver los PV que se creen.

Para el despliegue de las maquinas virtuales he utilizado terraform para la creación de las mismas sobre KVM (libvirt).

Para desplegar el software de kubernetes en los nodos y posterior configuración del cluster he utilizado Installing your Kubernetes homelab cluster in minutes with Ansible de Mark Perdue con alguna modificación/corrección.

Para el PVC, lo mejor que he visto ha sido Kubernetes : NFS and Dynamic NFS provisioning de Ccaplat. Aún no lo he probado, será el siguiente paso.

Navegando por Kubernetes

Siempre que me he tenido que mover por kubernetes lo he hecho basandome en pequeñas guias que realizan el despliegue del recurso. Poquito a poco fui viendo las opciones de los deployment, statefulset, daemonset y todo lo que en ese momento necesitaba. Sobre la marcha.

La sensación cuando tengo que modificar algun yaml para desplegar el recurso es de ir un poco a ciegas. ¿Es correcta esta opcion? Ni idea, probemos y ya nos dira kubernetes si es correcta o no cuando se aplique.

Para mi no era lo ideal. Basicamente lo que he llamado, aprender a las bravas. Aunque acudir a la ayuda de kubernetes.io puede aportar claridad, no conseguia quedarme contento. Por eso hay varios comandos de kubectl que si que pueden hacerlo sin salirte de shell.

El primero es kubectl api-versions que te lista todos los recursos de la api. Luego con kubectl explain y la opción --recursive se puede obtener el listado con sus indentaciones de la definición del recurso (los items/nodes). Y si hacemos kubectl explain resource.<item>.<otro-item> podemos ir viendo las definiciones y explicaciones de lo que hacen los parametros de la definición del recurso.

Con eso ya me he quedado más contento. Sé en que me punto me encuentro en lo que respecta a la sintaxis de un yaml de kubernetes cuando tengo que hacer alguna modificación en alguna parte en la que no estoy familiarizado.

Un ejemplo aplicado a los pvc:

kubectl explain persistentvolumeclaims
kubectl explain persistentvolumeclaims --recursive
kubectl explain persistentvolumeclaims.spec --recursive
kubectl explain persistentvolumeclaims.spec.resources.requests

Comando weather en linux

Para los que no conozcan el comando weather de linux puede resultar sorprendente que exista una utilidad de linux que pueda recuperar información meteorológica de las estaciones del tiempo del NOAA (the USA National Oceanic and Atmospheric Administration) y del NWS (the USA National Weather Service). Además, no solo sirve para estaciones ubicadas en EEUU sino que tambien sirva para estaciones ubicadas por el resto del mundo. España tiene unas cuentas de ellas.

Cuando instalas la herramienta, existe un fichero llamado /usr/share/weather-util/stations.gz que tiene la relación entre el nombre de la estacion segun el ICAO Airport Code y la url del NOAA donde se encuentra el fichero con los datos que regularmente reporta la estación meteorológica ubicada en ese lugar.

[levt]
description = Vitoria, Spain
location = (0.7484554, -0.0474148)
metar = https://tgftp.nws.noaa.gov/data/observations/metar/decoded/LEVT.TXT

[levx]
description = Vigo / Peinador, Spain
location = (0.7368198, -0.1506801)
metar = https://tgftp.nws.noaa.gov/data/observations/metar/decoded/LEVX.TXT

España tiene asignados los códigos [leXX] para todos sus aeropuertos como se puede ver en Lista de ICAO code L. No todos los aeropuertos tienen estación meteorológica integrada con el NOAA.

Es curioso ver, que existen dos estaciones en España que son desconocidas su nombre y ubicación: [lebr] y [letu]

Así que el comando linux weather no es mas que un curl / wget a la URL asociada el código de la estación  (atributo metar) y parsear los valores o directamente pasar a mayúsculas y hacer un wget a la url base https://tgftp.nws.noaa.gov/data/observations/metar/decoded/CODIGO_ICAO.TXT

PD: El Automated Surface Observing Systems (ASOS) gestiona todo el tema relacionado con las estaciones. Aunque cuesta trabajo encontrarlo, tiene una detallada información de todo el proceso. Hay incluida una Guia de Usuario

Setup de Cordobasur

Durante las semanas de vacaciones me he entretenido en activar la raspberry pi y medir la temperatura de casa diferentes habitaciones mediante los sensores de temperatura y humedad de Xiaomi LYWSD03MMC.

La ideal era solo eso, pero fue cambiando con el paso del tiempo para disponer de lo siguiente:

• Conectividad desde el exterior de casa a la raspberry pi [SSH]
• Conectividad desde el exterior mediante VPN para evitar tener que publicar puertos adicionales a otros recursos de casa [OPENVPN] en la raspberry pi
• Encendido mediante Wake On LAN (WOL) de otros equipos de casa [Scripts + Apache]
• Despliegue de un sistema de sondeo de los diferentes sensores de Xiaomi, que inicialmente fue MRTG pero luego lo cambie para utilizar [Cacti+MariaDB+Apache]
• Sistema de notificación utilizando Telegram [script que llama a curl]
• Protección del sistema de ataques por fuerza bruta de los puertos publicados en el router SSH/OPENVPN [Fail2ban]

Lo anterior son todas aquellas cosas que necesito tener funcionando las 24h. El consumo de la raspberry pi es muy bajo, por lo que no tiene apenas costo.

Luego, tengo otros servicios que requieren de mayor consumo de cpu y memoria por lo que no tienen cabida en la Raspberry Pi, por lo que tengo un Intel NUC con 64 GB, en donde he despliegue aquellos servicios que son bajo demando. Una vez encendido el equipo mediante WOL desde la rasbperry pi, he desplegado lo siguiente

• Cluster de Kubernetes basado en tres nodos que levanto con virsh
• Repositorios git [publicados en el apache].
• Gitweb para una consulta rapida del contenido de los repositorios (no para realizar commits/push/pull, solo para verlo dentro del apache y poder navegar por sus contenidos)

Así que el primer problema consistía en obtener la IP del router y utilizar un servicio de IP dinámica (noip.com). De esa forma, obtengo un nombre DNS que apunta siempre a la IP pública del router.

El segundo paso ha sido poner una ip fija dentro de la LAN de casa para que la raspberry cuando se encendiera utilizara siempre lo mismo. Esto se puede hacer configurándola en la interfaz de red de la raspberry o mediante haciendo que el DHCP del router le asigne siempre la misma utilizando su mac-address. En mi caso he optado por la segunda opción. De hecho, el otro equipo que tengo (el intel nuc) también toma la ip por DHCP pero tiene una reserva con su mac-address.

El tercer paso ha sido publicar los puertos del SSH y de OPENVPN en el router para que desde el exterior se dirija la comunicación hacia los correspondientes servicios (SSH, OPENVPN). No he utilizado los tradicionales (22/tcp y 1194/udp) sino que he utilizado otros para evitar escaneos sencillos.

Como medida adicional he instalado fail2ban para que me detecte intentos de hacer login en los servicios SSH/OPENVPN y si superan el máximo numero de intentos (5), sea baneada la ip del equipo remoto durante un par de horas. Si ocurre algo de eso, es notificado por telegram.

También he habilitado el doble factor de autenticación en el SSH cuando se utiliza password. Podria haber deshabilitado el acceso mediante password y permitir solo el acceso con certificado SSH, pero mantengo los dos métodos de acceso.

El cuarto paso ha sido la creación de un script de notificación via telegram. El script permite mandar mensajes de texto a un canal de chat de Telegram utilizando un bot.

Para que Cacti pueda graficar los valores de temperatura de los sensores LYWSD03MMC, he hecho un script específico al que se la pasa la mac-address y desde la raspberry mediante bluetooth sondeo los valores de temperatura de los siete sensores que tengo instalados en cada habitación de la casa (cocina, salón, estudio, baño chico, baño grande, cuarto de invitados y dormitorio). Este sondeo se realiza cada cinco minutos.

Esto en lo que atañe a la raspberry pi y aquellos servicios consideras 24h. Como ya dije, los servicios on-demand están instalados en el Intel NUC. El encendido del mismo se puede hacer mediante un script que llama a WoL para encender el Intel NUC, pero también habilite en el apache un directorio desde el cual se permite ejecutar el script de WoL de Intel NUC, manteniendo dos formas de encenderlo (línea de comandos y apache).

El primer paso fue habilitar WOL en la UEFI para que si llegaba un paquete de WOL a la red de la tarjeta del Intel NUC. El mensaje de WOL hace uso de lo que se denomina paquete mágico que no es más que un mensaje de red formado por una cadena de seis bytes con valor hexadecimal FF FF FF FF FF FF seguida de 16 repeticiones de la dirección MAC del destino para poder arracarlo. El mensaje de red se envía a los puertos 7 o 9 UDP.

Cuando la tarjeta de red del equipo destino detecta el paquete, comprueba que las 16 MAC corresponden con la suya, enviando una señal eléctrica a la placa base para que encienda.

Es lógico que para utilizar esta forma de arranque remoto es necesario conocer la dirección MAC-ADDRESS del destino.

Posteriormente, se instalan las herramientas de git para gestionar el repositorio y el apache para publicar por HTTP, permitiendo el acceso remoto al repositorio. Una vez creado el repositorio se agrega gitweb para publicar un visor del repositorio en el apache y accesible mediante el navegador.

Lou Grant

Le pase a un amigo un artículo de Jot Down Magazine sobre la serie Lou Grant que es notable por la utilización del artículo para trazar los problemas de una profesión que considero importante pero también es un gran engaño perpetrado por ellos mismos (o por sus dueños).

En cualquier caso hay algo en lo que no caen los periodistas. Para que el conjunto de ellos hagan un buen trabajo es necesario que sus lectores sean muy infieles. Los lectores debemos ser muy promiscuos, de lo contrario la cagaremos al permitirnos ver solo un lado de la verdad (o de la mentira) que nos cuenten.

GOTO SanlucarBarrameda:

Técnicamente empezó hace dos años. Lo que parecía una ruta loca cuando escuché que había gente que la hacía, sobre todo por el modo tan faltó de preparación. Hacer 110 km no es algo que se deba improvisar o por lo menos así lo pienso.

Lo primero que hice fue mirar por qué caminos iban. El camino no parece que tenga mucha complicación. Una primera parte en la que cruzas Sevilla de Este a Oeste (Km 13) para llegar al corredor natural del río Guadaira que circula paralelo. Siguiendo el corredor damos con la desembocadura del Guadaira en el Guadalquivir (Km 40). Posteriomente te separas del río para adéntrate en los campos de cereales hasta que retomas el camino pegado al río Guadalquivir en la antigua carretera del práctico (Km 55). Allí hasta el Km 90 el río es un fiel compañero mientras se sigue lla ruta del práctico que se deja atrás para adentrarse en el parque del Pinar de Algaida. Cuando se sale del mismo solo quedan 10 Km mal contados hasta llegar a Sanlúcar de Barrameda y completar los 110 Km.

Sabiendo esto solo hay que preparar físicamente para aguantar sin problemas seis horas en bici que se necesitan. Con cuatro horas de media semanal en bici estática es suficiente. El ritmo que debes seguir debe ser el más alto que puedas llevar durante una hora. Otra cuestión es no llevar culotes acolchados. Es mejor no acostumbrarse. Luego en la ruta llevarás uno y se notará. Otra cosa sera es el agua y comida. Dos litros y dos bocadillos es suficiente.

Hay que tener en cuenta que se tiene que regresar a casa. Para eso se me ocurrió ir el día de antes. Dejar el coche en Sanlúcar y regresar en autobús que lleva a Jerez y en Jerez coger el tren de media distancia de Cadiz-Jaen. Con Google Maps se puede bichear bien.

El día 22 de enero fue el primer intento. El cuál fue terminado con éxito y con un viento de noroeste que acompañó todo el viaje. Ese es un aspecto fundamental. No encontrar viento de cara que vuelven la aventura algo criminal. En esta ocasión el viento me irá acompañando de lado lo que ayudará pero tampoco perjudicará. windfind es tu amigo.