Forem: Daniel M.

Cómo resolver 'grub_memcpy not found' en Manjaro

Daniel M. — Mon, 09 Feb 2026 09:39:07 +0000

Dentro de los ordenadores portátiles, o laptops, existe un pequeño componente consumible, la pila de litio, que cambiarla puede llegar a ser un suplicio. No me refiero al hecho de quitar la gastada y poner otra como quien le cambia las pilas a un mando, sino a dos hechos unidos que a su vez te consumen a ti:

desmontar la parte trasera del portátil.
recuperar la parte del sistema que gestiona el arranque, el bootloader.

En este tutorial recopilo los pasos que he seguido para volver a habilitar el bootloader de Manjaro, una distribución basada en Arch Linux. El portátil es un Slimbook PROX14 que, por suerte, contiene la pila de litio debajo de la batería, por lo que el desmontaje no era complicado. Una vez cambiada la pila, vamos a seguir los pasos pero antes saber cuál era el síntoma:

error: symbol 'grub_memcpy' not found.
Entering rescue mode...
grub rescue>

y hasta aquí, no esperemos que venga nadie a rescatarnos. Hemos perdido la configuración UEFI y tenemos una partición raíz cifrada con LUKS. El workaround ha sido arrancar con un Manjaro instalado en un USB y elegir un bootloader de ese sistema, ubicado en la carpeta:

/boot/EFI/Manjaro

Recuperamos el bootloader

1. Arrancar con un Manjaro Live USB

Arranca el equipo desde un USB de Manjaro en modo UEFI. Este sistema se instaló con Balena Etcher.

Abrimos una terminal para seguir estos pasos.

2. Identificar las particiones

lsblk -f

Ejemplo típico:

Partición Tipo Uso Ruta

nvme0n1p1 vfat EFI /boot/efi
nvme0n1p2 crypto_LUKS Sistema cifrado /

3. Desbloquear la partición cifrada

sudo cryptsetup open /dev/nvme0n1p2 luksroot

Insertamos la contraseña de ese sistema cifrado y nos aparece si buscamos en:

ls -l /dev/mapper/

4. Montar el sistema

sudo mount /dev/mapper/luksroot /mnt
sudo mount /dev/nvme0n1p1 /mnt/boot/efi

No nos debería dar ningún error y si listamos el directorio /mnt, nos debería ir saliendo nuestro sistema nativo:

ls -l /mnt

5. Montar sistemas virtuales

Esta parte fue clave, lo obvié en un primer intento y no lo conseguí. Con esos pasos fue distinto y no salieron errores en los pasos posteriores.

sudo mount --bind /dev /mnt/dev
sudo mount --bind /proc /mnt/proc
sudo mount --bind /sys /mnt/sys
sudo mount --bind /run /mnt/run

6. Entrar en el sistema instalado mediante chroot

sudo chroot /mnt

7. Asegurar que EFI variables está montado

mount -t efivarfs efivarfs /sys/firmware/efi/efivars

8. Reinstalar GRUB limpio

grub-install   --target=x86_64-efi   --efi-directory=/boot/efi   --bootloader-id=Manjaro   --recheck

El resultado de los pasos 7 y 8:

[manjaro /]# mount -t efivarfs efivarfs /sys/firmware/efi/efivars
[manjaro /]# grub-install \ --target=x86_64-efi \ --efi-directory=/boot/efi \ --bootloader-id=Manjaro \ --recheck
Installing for x86_64-efi platform. 
Installation finished. 
No error reported.

9. Regenerar la configuración de GRUB

grub-mkconfig -o /boot/grub/grub.cfg

10. Crear el fallback de arranque

En ese primer intento que comentaba en el paso 5, seguí los pasos que podrían darse para Arch Linux, pero al comprobar que Manjaro tiene su propio sistema, dupliqué algunas carpetas de /boot. Expongo el contenido de la carpeta /boot/efi/EFI:

[manjaro /]# ls -laR /boot/efi/EFI

/boot/efi/EFI: total 24 
drwxr-xr-x 6 root root 4096 ene 8 10:27 . 
drwxr-xr-x 4 root root 4096 ene 1 1970 .. 
drwxr-xr-x 2 root root 4096 ago 14 2024 boot 
drwxr-xr-x 4 root root 4096 ene 8 10:58 EFI 
drwxr-xr-x 2 root root 4096 ene 8 10:25 GRUB 
drwxr-xr-x 2 root root 4096 ago 14 2024 Manjaro

/boot/efi/EFI/boot: total 268 
drwxr-xr-x 2 root root 4096 ago 14 2024 . 
drwxr-xr-x 6 root root 4096 ene 8 10:27 .. 
-rwxr-xr-x 1 root root 266240 sep 29 08:24 bootx64.efi

/boot/efi/EFI/EFI: total 16 
drwxr-xr-x 4 root root 4096 ene 8 10:58 . 
drwxr-xr-x 6 root root 4096 ene 8 10:27 .. 
drwxr-xr-x 3 root root 4096 ene 8 10:58 EFI 
drwxr-xr-x 2 root root 4096 ene 8 10:27 manjaro

/boot/efi/EFI/EFI/EFI: total 12 
drwxr-xr-x 3 root root 4096 ene 8 10:58 . 
drwxr-xr-x 4 root root 4096 ene 8 10:58 .. 
drwxr-xr-x 2 root root 4096 ene 8 10:58 manjaro

/boot/efi/EFI/EFI/EFI/manjaro: total 164 
drwxr-xr-x 2 root root 4096 ene 8 10:58 . 
drwxr-xr-x 3 root root 4096 ene 8 10:58 .. 
-rwxr-xr-x 1 root root 159744 ene 8 10:58 grubx64.efi

/boot/efi/EFI/EFI/manjaro: total 164 
drwxr-xr-x 2 root root 4096 ene 8 10:27 . 
drwxr-xr-x 4 root root 4096 ene 8 10:58 .. 
-rwxr-xr-x 1 root root 159744 ene 8 10:27 grubx64.efi

/boot/efi/EFI/GRUB: total 164 
drwxr-xr-x 2 root root 4096 ene 8 10:25 . 
drwxr-xr-x 6 root root 4096 ene 8 10:27 .. 
-rwxr-xr-x 1 root root 159744 ene 8 10:25 grubx64.efi

/boot/efi/EFI/Manjaro: total 344 
drwxr-xr-x 2 root root 4096 ago 14 2024 . 
drwxr-xr-x 6 root root 4096 ene 8 10:27 .. 
-rwxr-xr-x 1 root root 344064 feb 8 21:32 grubx64.efi

Me centro en las importantes, /boot/efi/EFI/Manjaro y la del fallback, /boot/efi/EFI/boot. El resto las borraré después, en realidad son dos que contienen las otras 6. Copio el archivo grubx64.efi y lo sobrenombro en la ubicación de la fallback.

cp /boot/efi/EFI/Manjaro/grubx64.efi    /boot/efi/EFI/boot/bootx64.efi

Aunque sería raro que no fuese así, aquí compruebo que los tamaños coinciden.

[manjaro /]# cp /boot/efi/EFI/Manjaro/grubx64.efi \ /boot/efi/EFI/boot/bootx64.efi 
[manjaro /]# ls -l /boot/efi/EFI/boot/bootx64.efi 
-rwxr-xr-x 1 root root 344064 feb 8 21:46 /boot/efi/EFI/boot/bootx64.efi 
[manjaro /]# ls -l /boot/efi/EFI/Manjaro/grubx64.efi 
-rwxr-xr-x 1 root root 344064 feb 8 21:32 /boot/efi/EFI/Manjaro/grubx64.efi

11. Salir y reiniciar

exit
sudo reboot

y extraímos el USB con el Manjaro Live.

Limpieza del GRUB y orden de arranque

Si todo ha ido bien y nuestro sistema nativo ha arrancado, procedemos a poner un poco de orden.

1. Ver entradas UEFI

Como comentaba en el paso 5 del bloque anterior, tenía más de dos carpetas en /boot por lo que decidí comprobar cuáles eran las mal copiadas. Con el siguiente comando, puedes ver el registro del arranque y decidir qué hacer con las carpetas redundantes. En mi caso, las moví a un backup y probé si todo iba bien, por lo que decidí borrarlas a posteriori.

sudo efibootmgr -v

El contenido:

BootCurrent: 0001 Timeout: 1 seconds 
BootOrder: 0001,0000 
Boot0000* Manjaro HD(1,GPT,73b40a30-b2a6-4754-a2c9-d97789fc433c,0x1000,0x96000)/\EFI\MANJARO\GRUBX64.EFI dp: 04 01 2a 00 01 00 00 00 00 10 00 00 00 00 00 00 00 60 09 00 00 00 00 00 30 0a b4 73 a6 b2 54 47 a2 c9 d9 77 89 fc 43 3c 02 02 / 04 04 36 00 5c 00 45 00 46 00 49 00 5c 00 4d 00 41 00 4e 00 4a 00 41 00 52 00 4f 00 5c 00 47 00 52 00 55 00 42 00 58 00 36 00 34 00 2e 00 45 00 46 00 49 00 00 00 / 7f ff 04 00 
Boot0001* UEFI OS HD(1,GPT,73b40a30-b2a6-4754-a2c9-d97789fc433c,0x1000,0x96000)/\EFI\BOOT\BOOTX64.EFI0000424f dp: 04 01 2a 00 01 00 00 00 00 10 00 00 00 00 00 00 00 60 09 00 00 00 00 00 30 0a b4 73 a6 b2 54 47 a2 c9 d9 77 89 fc 43 3c 02 02 / 04 04 30 00 5c 00 45 00 46 00 49 00 5c 00 42 00 4f 00 4f 00 54 00 5c 00 42 00 4f 00 4f 00 54 00 58 00 36 00 34 00 2e 00 45 00 46 00 49 00 00 00 / 7f ff 04 00 data: 00 00 42 4f

Poner Manjaro como primera opción

sudo efibootmgr -o 0000,0001

El contenido:

➜ ~ sudo efibootmgr -o 0000,0001 
BootCurrent: 0001 Timeout: 1 seconds BootOrder: 0000,0001 
Boot0000* Manjaro HD(1,GPT,73b40a30-b2a6-4754-a2c9-d97789fc433c,0x1000,0x96000)/\EFI\MANJARO\GRUBX64.EFI 
Boot0001* UEFI OS HD(1,GPT,73b40a30-b2a6-4754-a2c9-d97789fc433c,0x1000,0x96000)/\EFI\BOOT\BOOTX64.EFI0000424f

El arranque de Manjaro sería el primero y si falla, el fallback toma el testigo. Este último registro se podría eliminar con:

sudo efibootmgr -b 0001 -B

Pero mejor dejarlo así.

2. Limpiar copias antiguas (opcional)

sudo rm -rf /boot/efi/EFI/backup-EFI
sudo rm -rf /boot/efi/EFI/backup-GRUB

Y hasta aquí, he podido restaurar el sistema de arranque de Manjaro sin víctimas. Mis agradecimientos a Juanra, Alejandro y José Luis porque este tutorial es un compendio de todos sus consejos.

Foto: "Albion Low Loader Heavy Haulage 1951
by pschube is licensed with CC BY 2.0

Servicios usados para un Data Lake en AWS

Daniel M. — Tue, 12 Mar 2024 09:45:48 +0000

Este artículo no es una guía, sino una serie de anotaciones de los servicios usados para montar un data lake con AWS. Partiendo de datos extraídos de una base de datos Amazon Aurora PostgreSQL, del que ya facilité el script usado en este mismo espacio, y un esquema previo, fuimos preparando esta plataforma. Por mi parte, mi rol fue el de habilitar los flujos y las automatizaciones. Uno de los puntos en los que se dedicó más tiempo fue a afinar permisos para evitar posibles agujeros de seguridad.

Pero, ¿qué es un data lake? Se trata de un repositorio en el que se almacenan datos en bruto con los que obtener información, a través de analítica y "cocina", para facilitar la toma de decisiones, ya sean estratégicas o de marketing.

Como decía al principio, la información expuesta abajo son apuntes de los servicios usados, descartes y precisiones que se hicieron, especialmente en el AWS Identity and Access Management (IAM) para determinar los roles.

⚠️ Este proyecto partió de cero con un esquema que fue modificándose con el tiempo haciéndolo más sencillo. Los nombres de los roles son ejemplos.

Hecha la introducción, y recordando que ya subí el script con el que se extraían los datos de una instancia de Amazon Aurora PostgreSQL (RDS), comento los servicios usados:

IAM

AWS Identity and Access Management (IAM) es un servicio web que lo ayuda a controlar de forma segura el acceso a los recursos de AWS. Con IAM, puede administrar de forma centralizada los permisos que controlan a qué recursos de AWS pueden acceder los usuarios. Utilice IAM para controlar quién está autenticado (ha iniciado sesión) y autorizado (tiene permisos) para utilizar recursos.

Roles

De nombre AWSGlueServiceRole-crawlers, estos son los permisos asociaciados a este rol:

AWSCodeCommitFullAccess (AWS managed)
AWSGlueServiceRole (AWS managed)
AWSGlueServiceRole-crawlers-s3Policy (Customer managed, expuesto más abajo)
AWSKeyManagementServicePowerUser (AWS managed)

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": [
          "databrew.amazonaws.com",
          "kms.amazonaws.com",
          "glue.amazonaws.com",
          "codecommit.amazonaws.com"
        ]
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

Policies

AWSGlueServiceRole-ics-glue

Rol para albergar la calendarización con permisos de tomar y depositar objetos en un bucket S3.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject"
      ],
      "Resource": [
        "arn:aws:s3:::calendar-files-eu*"
      ]
    }
  ]
}

AWSGlueServiceRole-crawlers-EZCRC-s3Policy

Recuerdo que nos tomó cierto tiempo hasta descubrir que era imprescindible indicar las acciones Encrypt y Decrypt de manera explícita.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "VisualEditor0",
      "Effect": "Allow",
      "Action": [
        "s3:PutObject",
        "s3:GetObject",
        "s3:DeleteObject",
        "kms:GenerateDataKey",
        "kms:Encrypt",
        "kms:Decrypt"
      ],
      "Resource": [
        "arn:aws:kms:us-west-2:[AWS_ID]:key/[appflow-key]",
        "arn:aws:kms:us-west-2:[AWS_ID]:key/[rds_key]",
        "arn:aws:kms:us-west-2:[AWS_ID]:key/[ssh_key]",
        "arn:aws:s3:::datalake/ga4-funnel-events-flow/",
        "arn:aws:s3:::datalake/ga4-user-ids-flow/",
        "arn:aws:s3:::datalake/ga4-user-engagement-flow/",
        "arn:aws:s3:::datalake/ga4-traffic-flow/",
        "arn:aws:s3:::datalake/ga4-user-searches-flow/",
        "arn:aws:s3:::datalake/ga4-destinations-flow/",
        "arn:aws:s3:::datalake/ga4-listing-views-referrers-flow/",
        "arn:aws:s3:::datalake/raw_internal/export/",
        "arn:aws:s3:::datalake/processed_data/*"
      ]
    }
  ]
}

Nota: ga4 es la implementación de Google Analytics 4.

KMS

AWS KMS sirve para cifrar datos en sus cargas de trabajo de KMS, firmar datos de manera digital, cifrar dentro de sus aplicaciones con SDK de cifrado de AWS y generar y verificar códigos de autenticación de mensajes. En el JSON de arriba aparecen expuesto tres, que están descritos en este apartado. El KMS viene representado por una ristra de números y caracteres típico de una clave pública. En este caso, lo hemos cambiado por el nombre y puesto entre corchetes para indicar que en realidad es otro dato el que debería ir ahí y que, por seguridad, no se expone.

appflow_key, se trata de la clave que autoriza el acceso de servicios externos como Google Analytics. Más información en la sección de Integración de SaaS de AWS.
rds_key, la clave de autorización del intercambio de información desde una instancia del servicio RDS.
ssh_key, la conexión con las instancias.

CodeCommit

Este servicio es un repositorio de código, usado para alojar las versiones de los distintos scripts usados por la persona que ostente el rol de analista. CodeCommit es sencillo de implementar y automatiza cualquier cambio desde Athena, es decir, si se modifica el script, esta acción conlleva hacer git add, commit y push. No consume apenas porque para este cometido no llega a superar la capa gratuita de AWS. Dentro de Glue cabe también la posibilidad de usar GitHub, pero preferimos usar el nativo de AWS.

Glue

AWS Glue es un servicio de integración de datos sin servidor que facilita a los usuarios de análisis descubrir, preparar, migrar e integrar datos de varios orígenes. Puede utilizarlo para análisis, machine learning y desarrollo de aplicaciones. También incluye herramientas adicionales de productividad y operaciones de datos para la creación, la ejecución de trabajos y la implementación de flujos de trabajo empresariales.

Como sysadmin, se me escapa el uso más allá de acceder a él para preparar las automatizaciones con otros servicios.

DataBrew

Este servicio fue descartado porque conseguimos extraer la información directamente de la base de datos en un formato, .parquet, que le venía bien al analista de datos.

S3

Servicio de alojamiento donde albergar la información. Tanto en el script como en estas notas tiene el nombre raíz de "datalake".

Athena

Amazon Athena es un servicio de análisis interactivo y sin servidor creado en marcos de código abierto, lo que lo hace compatible con formatos abiertos de archivos y tablas. Athena proporciona un método simplificado y flexible de analizar petabytes de datos donde residan. Analice datos o cree aplicaciones a partir de un lago de datos de Amazon Simple Storage Service (S3) y más de 30 orígenes de datos, que incluyen orígenes de datos en las instalaciones u otros sistemas en la nube que usan SQL o Python.

En nuestro caso, comenzamos implementando Athena conectándolo a la base de datos vía Metabase con el conector oficial.

Amazon Athena

Script de exportación

Alojado en una instancia EC2 y programado, en estas notas ha sido enlazado en más de una ocasión y qué menos que indicarlo aquí también como otro de los requisitos:

Un script para exportar selectivamente tablas de una BD en AWS.

Termino recordando de qué se trata este artículo, son el esbozo de unas anotaciones para construir un data lake con AWS del que partimos con más corazón que conocimientos y un esquema que fue modificándose poco a poco.

Un script para exportar selectivamente tablas de una BD en AWS

Daniel M. — Fri, 08 Mar 2024 11:14:42 +0000

Eres el sysadmin de una empresa y el departamento destinado a mejorar el producto te solicita un "data lake" donde albergar datos en bruto procedentes de bases de datos para cocinarlos y tomar decisiones. Una de las partes fundamentales de un proyecto así es la extracción de datos, así como su fiabilidad y rapidez en el proceso, que en este caso es diario. Preparas una extracción pero dura demasiado y son gigas y gigas de transferencia que no necesitan, por lo que, finalmente, comprobáis que sólo requieren información de unas 90 tablas de un total de más de 14000 que tiene el proyecto completo. La plataforma está montada en AWS y hemos de ver cómo hacerles llegar esa información totalmente optimizada en tiempo, filtrado y orden. Contamos con una pequeña máquina de EC2 en la infraestructura donde alojamos scripts, por lo que es el sitio idóneo para ello. A partir de aquí, el comando start-export-task se convierte en nuestro aliado.

¿Qué servicios AWS usaremos?

El listado de servicios que usaremos son los siguientes:

S3, donde se albergan los datos.
RDS, la instancia de la base de datos. En este caso, postgres.
EC2, la máquina donde configuramos el script.
SNS, el servicio de notificaciones para envíos por correo.

¿Qué requisitos necesitamos?

La máquina donde alojaremos el script ha de tener instalado AWS CLI. Se presupone que en una máquina de AWS ha de venir de serie, pero por si queremos hacerlo en otra instancia, ya sea una máquina virtual o en nuestro propio equipo, es muy sencillo, sólo hay que copiar el siguiente comando proporcionado por AWS:

$ curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
unzip awscliv2.zip
sudo ./aws/install

Para comprobar que está todo correcto:

 ~ aws --version
aws-cli/2.7.35 Python/3.9.11 Linux/5.15.0-97-generic exe/x86_64.ubuntu.20 prompt/off

Ya lo tenemos todo para dejar preparado un script que haga lo siguiente:

Eliminar la copia del día anterior. Los datos no son necesario albergarlos y no pueden mezclarse, por lo que se pueden borrar.
Mediante la opción start-export-task del comando rds, identificar la base de datos y las tablas que queremos exportar con el parámetro --export-only. En este caso, hemos puesto 6 tablas.
Ha de existir un rol en IAM que tenga acceso de lectura en RDS y escritura en S3, así como la capacidad de crear "buckets".
Se hizo un case para enviar un correo según el estado en el que se encontraba la exportación. Se hacen comprobaciones cada 120 segundos y mientras fuera distinto de "COMPLETE", vuelve a esperarse 120 segundos antes de otra comprobación del estado. Para conocer el estado, la línea es identifier postgres-partial-export-$DATE | jq -r.

#!/bin/bash
set -ex
DATE=$(date +%Y-%m-%d-%H-%M)
PRO_DBNAME=database
echo "Removing old data"
aws s3 rm s3://datalake/raw_internal/export --recursive
echo "Copying ${PRO_DBNAME} @ postgres tables to the Data Lake directory"
aws rds start-export-task \
--export-task-identifier postgres-partial-export-$DATE \
--source-arn arn:aws:rds:us-west-2:[AWS_ID]:cluster:[nombre_cluster_rds] \
--s3-bucket-name datalake \
--s3-prefix raw_internal/export \
--export-only database.public.tabla1 database.public.tabla1 database.public.tabla2 database.public.tabla3 database.public.tabla4 database.public.tabla5 database.public.tabla6 \
--iam-role-arn arn:aws:iam::[AWS_ID]:role/rds-export-to-s3 \
--kms-key-id [KMS_ID] \
--no-cli-pager
echo "Process started"
while [ "$status" != "COMPLETE" ]; do
echo "What's the status?"
echo $status
status=$(aws rds describe-export-tasks --export-task-identifier postgres-partial-export-$DATE | jq -r ".ExportTasks[].Status")
case $status in
"STARTING") sleep 120 ;;
"IN_PROGRESS") sleep 120 ;;
"CANCELING") sleep 120 ;;
"CANCELED")
echo "Canceled, sending an email"
aws ses send-email --from [report@domain.com](mailto:report@domain.com) --to datascience[@domain.com](mailto:datalake@domain.com) --subject "Export status $status" --text "Hi, the export has been canceled. This email has been sent at $(date) via AWS CLI"
break
;;
"COMPLETE")
echo "Ready to move it to the main directory"
sleep 5
aws s3 mv s3://datalake/raw_internal/export/postgres-partial-export-$DATE/database/ s3://datalake/raw_internal/export --recursive
echo "Leaving successfully"
aws ses send-email --from [report@domain.com](mailto:report@domain.com) --to datascience[@domain.com](mailto:datalake@domain.com) --subject "Export status $status" --html "<p>Hi,</p> <p>the export status is $status.</p><p>The report: [https://us-west-2.console.aws.amazon.com/rds/home?region=us-west-2#exports-in-s3:](https://us-west-2.console.aws.amazon.com/rds/home?region=us-west-2#exports-in-s3:) </p><p>The export bucket: [https://us-west-2.console.aws.amazon.com/s3/buckets/datalake?region=us-west-2&prefix=raw_internal/export/&showversions=false](https://us-west-2.console.aws.amazon.com/s3/buckets/datalake?region=us-west-2&prefix=raw_internal/export/&showversions=false)</p> <p>This automated message has been sent at $(date) via AWS CLI, please do not reply.</p>"
;;
"FAILED")
echo "Failed, sending an e-mail"
aws ses send-email --from [report@domain.com](mailto:report@domain.com) --to datascience[@domain.com](mailto:datalake@domain.com) --subject "Export status $status" --text "Hi, the export has failed. Exports in Amazon S3: [https://us-west-2.console.aws.amazon.com/rds/home?region=us-west-2#exports-in-s3:](https://us-west-2.console.aws.amazon.com/rds/home?region=us-west-2#exports-in-s3:) //  This email has been sent at $(date) via AWS CLI"
break
;;
*) echo "Unknown response" ;;
esac
done
echo "Process finished"
exit 0

Programar el script

Hay dos opciones para hacer que el script se ejecute con periodicidad:

Cómo montar una VPN rápido y sin complicaciones donde quieras

Daniel M. — Fri, 08 Mar 2024 09:45:52 +0000

⚠️ Este tutorial sirve para montar una VPN en 5 minutos por si necesitas conexiones esporádicas a alguna red en concreto. Si lo usas de manera profesional, asegúrate de tener la paquetería de seguridad actualizada.

Dónde instalar el servidor VPN

Partimos de cero eligiendo una VPS según nuestros requisitos:

Si es para conectarnos a una red local del que queramos usar servicios, montamos una máquina virtual, Raspberry Pi o cualquier otra opción que nos ofrezca poder instalar una distribución de Ubuntu Server.
Si es para facilitarnos una IP específica de un país, ya sea porque trabajamos en un marketplace con geolocalización y necesitamos comprobar que sale la moneda local de inicio, entre otros casos. Si es así, en servicios como Digital Ocean o Linode podemos crear una VPS (Droplet en el caso de Digital Ocean) con Ubuntu Server.

Cómo instalar el servidor VPN

Saber cuál es nuestra IP real, podemos verla en whatismyip.com.
Una vez montada la instancia de Ubuntu Server según nuestras necesidades, descargamos el script de GitHub con permisos de root:
```
curl -O https://raw.githubusercontent.com/angristan/openvpn-install/master/openvpn-install.sh
```
Damos permisos de ejecución al script:
```
chmod +x openvpn-install.sh
```
Ejecutamos el script:
```
./openvpn-install.sh
```
Los primeros pasos para configurar la VPN son:
1. IP pública del servidor
2. Activar o no el soporte IPv6 (por defecto: no)
3. Puerto del VPN (por defecto: 1194)
4. Protocolo: (UDP)
5. DNS: En mi caso, he elegido OpenDNS (8)
6. Activar compresión (por defecto: no)
7. Personalizar las opciones de cifrado (por defecto: no)
¡Listo! Siguiendo con la configuración de openVPN, el script permite crear el primer archivo .ovpn de credenciales. Es muy sencillo, escribe un nombre y la opción de si incluir una contraseña o no de importación.

También podemos revisar el estado de openVPN con este comando:

systemctl status openvpn

Con un resultado similar a éste:

● openvpn.service - OpenVPN service
Loaded: loaded (/lib/systemd/system/openvpn.service; enabled; vendor preset: enabled)
Active: active (exited) since Tue 2022-08-30 09:21:07 UTC; 1 day 23h ago
Main PID: 12963 (code=exited, status=0/SUCCESS)
CPU: 4ms

Cómo añadir perfiles

Una vez hecho todo lo de arriba, no tenemos que volver a configurar nada si queremos crear perfiles y descargar las credenciales, o también revocarlas si queremos denegarles el acceso.

bash openvpn-install.sh

El menú es el siguiente:

Welcome to OpenVPN-install!
The git repository is available at: [https://github.com/angristan/openvpn-install](https://github.com/angristan/openvpn-install)
It looks like OpenVPN is already installed.
What do you want to do?
1) Add a new user
2) Revoke existing user
3) Remove OpenVPN
4) Exit
Select an option [1-4]:

Si queremos crear un nuevo perfil, elegimos la primera opción y los pasos serán los mismos que en la última parte del proceso inicial.

Nombre del perfil.
Como medida de seguridad, podemos asignarle una contraseña. Por ello, elegimos la segunda opción, “Use a password for the client” just to import it.
Copiar ese archivo a nuestro equipo local para conectarnos, o enviársela a una persona para que se conecte.

Cómo compartir el archivo con otras personas

Existe multitud de opciones, por ejemplo usando el comando scp para enviar remotamente copias de archivos, pero en este caso, vamos a hacerlo de una manera más simple.

cat archivo.ovpn

Entendiendo que hacemos el listado del archivo conectado por ssh a donde hemos instalado el servidor VPN, copiamos el contenido y, ya en local, usamos nuestro editor favorito:

vim archivo.ovpn

el archivo, al no existir en local, se crea nuevo y sólo necesitamos pulsar la tecla i ([INSERT]) y CTRL+shift+v para copiar el contenido.

El último paso para salir:

:wq

Cómo comprobar las conexiones recientes

Puedes ver quién está conectado a la instancia con:

cat /var/log/openvpn/status.log

Con un resultado como éste:

OpenVPN CLIENT LIST
Updated,2023-02-07 14:41:27
Common Name,Real Address,Bytes Received,Bytes Sent,Connected Since
[nombrearchivo],[IP de su equipo]:49161,2759574,2477388,2023-02-07 14:39:55
ROUTING TABLE
Virtual Address,Common Name,Real Address,Last Ref
10.8.0.2,gh-[name+username],[remote IP]:49161:49161,2023-02-07 14:41:26
GLOBAL STATS
Max bcast/mcast queue length,0
END

Cómo instalar el cliente VPN en Ubuntu

🦘 Si ya tienes configurado el cliente VPN en el sistema, salta directamente al punto 4. Los puntos previos son para instalar y activar los servicios. Los pasos a seguir son para distribuciones tipo Debian.

Abre un terminal e instala la paquetería necesaria

sudo apt install openvpn network-manager-openvpn

Activa y habilita el servicio openVPN:

sudo systemctl start openvpn && sudo systemctl enable openvpn

Revisa el estado del permiso con:

sudo systemctl status openvpn

obtendrás un mensaje similar a éste

● openvpn.service - OpenVPN service
Loaded: loaded (/lib/systemd/system/openvpn.service; enabled; vendor preset: enabled)
Active: active (exited) since Wed 2022-08-31 08:12:00 CEST; 3h 11min ago
Main PID: 1427 (code=exited, status=0/SUCCESS)
Tasks: 0 (limit: 37661)
Memory: 0B
CGroup: /system.slice/openvpn.service

Sube el archivo de configuración de extensión .ovpn

Tras seguir los pasos de cómo cargar el archivo .ovpn, puedes comprobar tu IP de nuevo en whatismyip.com y verificar si ha ido todo correcto.

Esto es todo, muy sencillo por ejemplo si tienes un servidor NAS en casa pero no quieres conectarlo a la red pública por privacidad. O tienes una cuenta compartida de algún servicio de streaming y necesitas que tu dispositivo se identifique como "hogar" una vez al mes ;-)

Termino este tutorial igual que como lo empecé, aconsejando que la paquetería de seguridad sea debidamente actualizada.

VPN known issues

Timeout error

En caso de que tengas un timeout en el log[1] y estás usando un escritorio distinto a GNOME, reinicia el servicio de network-manager. Dos opciones:

sudo service network-manager restart

o en su lugar

sudo systemctl restart systemd-networkd

Ubuntu usa network-manager en lugar del servicio por defecto de otras distribuciones.

[1] Obtén información tecleando:

grep openvpn /var/log/syslog

Slack

Encendiendo o apagando la VPN, Slack tendrá un retraso en la conexión de al menos 30-40 segundos en la app de Slack, como si se quedara desconectado. Vía web no me ha ocurrido y tampoco con otra aplicación.

Kubuntu

Hay un bug en KDE no resuelto. Importamos el archivo openvpn en la interfaz del network-manager. Se conecta, timeout, pero no tenemos más pistas. Lo llamativo es que conectándonos vía terminal va perfectamente:

sudo openvpn —config [file].ovpn

Hemos de abrir el archivo openvpn y extraer el bloque key en un archivo independiente. El bloque es algo como esto:

-----BEGIN OpenVPN Static key V1-----
92e2de5ae643729863zzzz4a0ebe952
.
.
.

cc05zxzxczczxxczxzxczxce902b498a5
-----END OpenVPN Static key V1-----

Sálvalo con la extensión [archivo].key

Por ello:

Abre la conexión openVPN ya creada en networkmanager.
Elige "Advanced..." en la pestaña VPN, luego TLS Settings, y cambia sólo dos cosas:
1. Modo a TLS-Crypt
2. y el hueco de "Key File", usa la ruta del archivo .key creado anteriormente. ¡No lo elimines!

Et voilà, la conexión funcionará.

Información sobre este bug:

Bug #1847144 “network-manager-openvpn config import ignores tls-...” : Bugs : network-manager-openvpn package : Ubuntu

Cómo montar un servidor de arranque PXE en Ubuntu 22.04

Daniel M. — Wed, 14 Dec 2022 17:54:11 +0000

Eres SysAdmin de una empresa y tienes por delante restaurar la distribución de 25 equipos que necesitan reinstalación. Puede considerarse una labor tediosa que piensas que es mejor automatizar, además añadiendo una configuración personalizada. Pero, ¿esto es posible? Sí. ¿Que puedo dejar instalados 25 equipos todos iguales de manera simultánea? ¡Sí! Existe PXE, como si tienes 90 o 100 equipos, pero, ¿qué es eso y cómo puedo montarlo? Vamos a ello, solo necesitaremos Ubuntu Server 22.04 instalado en una máquina virtual donde montaremos este servidor PXE para poder instalar imágenes de Ubuntu 22.04. Podemos elegir otra versión, como la 20.04, pero así comprobamos la compatibilidad con la más LTS más reciente. El último punto será crear la personalización que, como las opiniones, cada uno puede tener la suya.

Introducción

PXE es un protocolo utilizado para iniciar sistemas operativos a través de la red. Se puede usar este método para instalar nuestra distribución de GNU/Linux favorita en portátil, servidor u ordenador de escritorio a través de la red.

Configurando IP estática en Ubuntu Server 22.04 LTS

Antes de continuar, es mejor configurar el servidor de arranque PXE con una dirección IP estática. En esta primera sección, veremos cómo configurarla.

Para configurar una dirección IP estática en Ubuntu Server 22.04 LTS, abrimos el archivo de configuración de netplan con un editor de texto, en este caso nano:

sudo nano /ect/netplan/00-installer-config.yaml

E incluimos lo siguiente teniendo en cuenta que:

La interfaz en este caso es enp0s3, puedes saber cuál es al teclear ip a en el terminal,
192.168.180/24 es la IP que deseamos darle y la máscara de red de la configuración,
192.168.1.1 es la IP del router como servidor DHCP,
1.1.1.1 y 8.8.8.8 son direcciones DNS reconocidas

y podemos crearlo bajo nuestros propios parámetros.

#This is the network config written by 'subiquity'. IP addresses are an example
network:
  ethernets:
    enp0s3:
      dhcp4: no
      addresses:
        - 192.168.1.180/24
      routes:
        - to: default
          via: 192.168.1.1
      nameservers:
        addresses:
          - 1.1.1.1
          - 8.8.8.8
  version: 2

Para aplicar los cambios, ejecutamos:

sudo netplan apply

Creando la estructura de directorios requerida

Nuestra estructura de directorios tendrá la siguiente forma:

/pxeboot

y como subdirectorios

/config/ , donde guardaremos los archivos de arranque.
/firmware/, donde guardaremos los firmware.
/images/, donde guardaremos las imágenes que pueden listarse en el menú.

En el directorio /pxeboot/images/ copiaremos el contenido de cada imagen ISO en un subdirectorio por cada distribución. Esto lo veremos más adelante.

Para crear todos los directorios requeridos en un solo comando, ejecutamos:

sudo mkdir -pv /pxeboot/{config,firmware,images}

Descargando el código fuente de iPXE y compilación en Ubuntu 22.04

Estos pasos los haremos en nuestra carpeta de \home\$USER, lo último será moverlo todo a los directorios creados en el paso anterior.

En primer lugar, actualizamos los repositorios e instalamos los siguientes paquetes:

sudo apt update && sudo apt install build-essential liblzma-dev isolinux git -y

Clonamos el repositorio de iPXE en GitHub en nuestro servidor:

git clone https://github.com/ipxe/ipxe.git

Accedemos a la carpeta ipxe/src:

cd ipxe/src

Para configurar iPXE como arranque automático, hemos de crear el script correspondiente y relacionarlo con los firmwares de BIOS y UEFI cuando ya esté todo compilado.

Creamos el script de arranque para iPXE bootconfig.ipxe y lo abrimos con nuestro editor favorito:

nano bootconfig.ipxe

Copiando el siguiente contenido:

#!ipxe
dhcp
chain tftp://192.168.1.180/config/boot.ipxe

Recordemos que la IP es la que hemos configurado como IP estática del servidor.

Para compilar los firmwares de iPXE tanto para BIOS como para UEFI y relacionadrlo con el menú de arranque, ejecutamos el siguiente comando:

make bin/ipxe.pxe bin/undionly.kpxe bin/undionly.kkpxe bin/undionly.kkkpxe bin-x86_64-efi/ipxe.efi EMBED=bootconfig.ipxe

Esta tarea tomará varios minutos.

Copiando los firmwares ya compilados

Una vez que los firmwares de iPXE estén compilados, los copiamos en /pxeboot/firmware de nuestro servidor de arranque para que los equipos donde deseemos instalar los sistemas operativos puedan acceder vía TFTP.

sudo cp -v bin/{ipxe.pxe,undionly.kpxe,undionly.kkpxe,undionly.kkkpxe} bin-x86_64-efi/ipxe.efi /pxeboot/firmware/

Los archivos ipxe.pxe, undionly.kpxe, undionly.kkpxe, and undionly.kkkpxe son para arranques BIOS, mientras que ipxe.efi es para arranques UEFI.

Instalando y configurando DHCP y TFTP

Para que PXE arranque, necesitaremos un servidor DHCP y TFTP ejecutándose. En este caso, usaremos dnsmasq.

sudo apt install dnsmasq -y

Crearemos un nuevo archivo de configuración para dnsmasq. Renombramos el original /etc/dnsmasq.conf a /etc/dnsmasq.conf.backup de la siguiente manera:

sudo mv -v /etc/dnsmasq.conf /etc/dnsmasq.conf.backup

Creamos un archivo vacío:

sudo nano /etc/dnsmasq.conf

Y añadimos el siguiente contenido:

interface=enp0s3
bind-interfaces
domain=glampinghub.local
dhcp-range=192.168.1.181,192.168.1.190,255.255.255.0,12h
dhcp-option=option:router,192.168.1.1
dhcp-option=option:dns-server,1.1.1.1
dhcp-option=option:dns-server,8.8.8.8
enable-tftp
tftp-root=/pxeboot

# boot config for BIOS systems
dhcp-match=set:bios-x86,option:client-arch,0
dhcp-boot=tag:bios-x86,firmware/ipxe.pxe

# boot config for UEFI systems
dhcp-match=set:efi-x86_64,option:client-arch,7
dhcp-match=set:efi-x86_64,option:client-arch,9
dhcp-boot=tag:efi-x86_64,firmware/ipxe.efi

Para que los cambios tengan efecto, reiniciamos el servidor de dnsmasq:

sudo systemctl restart dnsmasq

Para comprobar que el servicio está ejecutándose, podemos comprobarlo de la siguiente manera:

sudo systemctl status dnsmasq

● dnsmasq.service - dnsmasq - A lightweight DHCP and caching DNS server
     Loaded: loaded (/lib/systemd/system/dnsmasq.service; enabled; vendor preset: enabled)
     Active: active (running) since Mon 2022-11-07 07:53:18 UTC; 3h 41min ago
    Process: 697 ExecStartPre=/etc/init.d/dnsmasq checkconfig (code=exited, status=0/SUCCESS)
    Process: 743 ExecStart=/etc/init.d/dnsmasq systemd-exec (code=exited, status=0/SUCCESS)
    Process: 768 ExecStartPost=/etc/init.d/dnsmasq systemd-start-resolvconf (code=exited, status=0/SUCCESS)
   Main PID: 766 (dnsmasq)
      Tasks: 1 (limit: 4576)
     Memory: 3.5M
        CPU: 35ms
     CGroup: /system.slice/dnsmasq.service
             └─766 /usr/sbin/dnsmasq -x /run/dnsmasq/dnsmasq.pid -u dnsmasq -7 /etc/dnsmasq.d,.dpkg-dist,.dpkg-old,.dpkg-new --local-service --trust-anchor=.,20326,8,2,e06d44b80b8f1d39a95c0b0d7c65d08458e880409bbc683457104237c7f8ec8d

nov 07 07:53:18 ubuntu2204pxe dnsmasq[766]: read /etc/hosts - 7 addresses
nov 07 07:53:18 ubuntu2204pxe systemd[1]: Started dnsmasq - A lightweight DHCP and caching DNS server.
nov 07 07:58:56 ubuntu2204pxe dnsmasq-dhcp[766]: DHCPDISCOVER(enp0s3) 08:00:27:37:b9:ec
nov 07 07:58:56 ubuntu2204pxe dnsmasq-dhcp[766]: DHCPOFFER(enp0s3) 192.168.1.123 08:00:27:37:b9:ec
nov 07 07:58:56 ubuntu2204pxe dnsmasq-dhcp[766]: DHCPDISCOVER(enp0s3) 08:00:27:37:b9:ec
nov 07 07:58:56 ubuntu2204pxe dnsmasq-dhcp[766]: DHCPOFFER(enp0s3) 192.168.1.123 08:00:27:37:b9:ec
nov 07 07:59:14 ubuntu2204pxe dnsmasq-dhcp[766]: DHCPDISCOVER(enp0s3) 08:00:27:37:b9:ec
nov 07 07:59:14 ubuntu2204pxe dnsmasq-dhcp[766]: DHCPOFFER(enp0s3) 192.168.1.123 08:00:27:37:b9:ec
nov 07 07:59:15 ubuntu2204pxe dnsmasq-dhcp[766]: DHCPDISCOVER(enp0s3) 08:00:27:37:b9:ec
nov 07 07:59:15 ubuntu2204pxe dnsmasq-dhcp[766]: DHCPOFFER(enp0s3) 192.168.1.123 08:00:27:37:b9:ec

Instalando y configurando el servidor NFS

Ubuntu 22.04 usa casper para arrancar la instalación modo "live". casper soporta arranque PXE solo a través del protocolo NFS. Por ello, para arrancar Ubuntu Desktop 22.04 a través de PXE, necesitaremos un servidor NFS que sea accesible por toda la red local.

Para instalar NFS en el servidor, ejecutamos:

sudo apt install nfs-kernel-server

Abrimos el archivo de configuración de NFS /etc/exports de la siguiente manera:

sudo nano /etc/exports

Y añadimos la siguiente línea al final:

/pxeboot           *(ro,sync,no_wdelay,insecure_locks,no_root_squash,insecure,no_subtree_check)

Para efectuar los cambios y compartir la nueva configuración para que sea visible, ejecuta:

sudo exportfs -av

Obteniendo el siguiente resultado por pantalla:

user@serverpxe:$ sudo exportfs -av
*:/pxeboot

Configurando iPXE

⚠️ La imagen ISO que descargaremos será de servidor, convirtiéndola en una versión de escritorio a través del autoinstalador de cloud-init como veremos en el último paso.

Descargamos la imagen de Ubuntu Server 22.04 en nuestro directorio de /home/$USER.

cd

wget https://releases.ubuntu.com/jammy/ubuntu-22.04.4-live-server-amd64.iso

Una vez descargado, montamos la imagen en el directorio /mnt:

sudo mount -o loop ubuntu-22.04.4-live-server-amd64.iso /mnt

Creamos un directorio dedicado a Ubuntu 22.04 en /pxeboot/images/:

sudo mkdir -pv /pxeboot/images/ubuntu-22.04

Para copiar los contenidos de la ISO, ejecutamos rsync de la siguiente manera:

sudo rsync -avz /mnt/ /pxeboot/images/ubuntu-22.04

Desmontamos la imagen de Ubuntu 22.04 LTS de '/mnt':

sudo umount /mnt

Creamos el archivo de configuración /pxeboot/config/boot.ipxe:

sudo nano /pxeboot/config/boot.ipxe

Y añadimos lo siguiente:

#!ipxe

set server_ip  192.168.1.180
set root_path  /pxeboot

menu Select an OS to boot
item ubuntu-22.04         Install Ubuntu 22.04 LTS
choose --default exit --timeout 10000 option && goto ${option}
:ubuntu-22.04

set os_root ubuntu-22.04
kernel tftp://${server_ip}/images/${os_root}/casper/vmlinuz
initrd tftp://${server_ip}/images/${os_root}/casper/initrd
imgargs vmlinuz initrd=initrd boot=casper netboot=nfs ip=dhcp nfsroot=${server_ip}:${root_path}/images/${os_root} ds=nocloud;s=/cdrom/nocloud/ autoinstall quiet splash ---
boot

El ejemplo de arriba es si montamos una sola imagen en el servidor. En el caso de que tengamos dos, por ejemplo Ubuntu 22.04 y Ubuntu 20.04, tendríamos un archivo similar a esto repitiendo los procesos de descarga, creación y montaje descritos arriba:

#!ipxe

set server_ip  192.168.1.180
set root_path  /pxeboot

menu Select an OS to boot
item ubuntu-20.04         Install Ubuntu 20.04 LTS
item ubuntu-22.04         Install Ubuntu 22.04 LTS
choose --default ubuntu-20.04 --timeout 10000 option && goto ${option}

:ubuntu-22.04
set os_root ubuntu-22.04
kernel tftp://${server_ip}/images/${os_root}/casper/vmlinuz
initrd tftp://${server_ip}/images/${os_root}/casper/initrd
imgargs vmlinuz initrd=initrd boot=casper maybe-ubiquity netboot=nfs ip=dhcp nfsroot=${server_ip}:${root_path}/images/${os_root} ds=nocloud;s=/cdrom/nocloud/ autoinstall quiet splash ---
boot

:ubuntu-20.04
set os_root ubuntu-20.04
kernel tftp://${server_ip}/images/${os_root}/casper/vmlinuz
initrd tftp://${server_ip}/images/${os_root}/casper/initrd
imgargs vmlinuz initrd=initrd boot=casper maybe-ubiquity netboot=nfs ip=dhcp nfsroot=${server_ip}:${root_path}/images/${os_root} ds=nocloud;s=/cdrom/nocloud/ autoinstall quiet splash ---
boot

Por comentar el menú de arriba, el parámetro ds=nocloud;s=/cdrom/nocloud/ captará la configuración de cloud-init y autoinstall comenzará automáticamente la instalación. Eliminar este último es útil para cuando tenemos equipos que no descartan por defecto seguir eligiendo el arranque por red tras la instalación, entrando así en un bucle de instalaciones que no terminaría nunca. Si estamos con otra cosa y en un equipo ya está instalado y reiniciado, quitando autoinstall nos encontraremos con una pregunta sobre proceder con la instalación y la necesidad de pulsar "Yes" o "No".

Autoinstall con cloud-init

Hasta ahora, hemos instalado una versión fresca de Ubuntu tal como vienen en las ISO. ¿Y si queremos hacer una instalación personalizada? Como introducción a este tema, cloud-init es un proyecto de Canonical, empresa responsable de Ubuntu, para hacer esas plantillas automatizadas. Es multiplataforma, por lo que funciona también con distribuciones como Fedora o Arch Linux.

cd /pxeboot/images

Accedemos, en este caso, a la imagen creada de Ubuntu 20.04:

cd ubuntu-20.04

y creamos la carpeta nocloud dentro de ella:

sudo mkdir nocloud && cd nocloud

Creando dos archivos nuevos:

sudo touch meta-data

meta-data se quedará así vacío, quedando el que nos interesa:

sudo nano user-data

En este archivo, copiaremos el contenido de este gist de GitHub donde podemos observar algunas personalizaciones:

Instalación de software concreto.
Nombre del host.
Creación de perfiles concretos con una configuración especial, tal la creación del archivo de claves públicas o la clave.
Sección interactiva, para añadir aquella que queramos desarrollar manualmente durante la instalación.
¡y un largo etcétera! Te animo a que leas la documentación sobre cloud-init al respecto.

El archivo, al estar escrito en formato YAML, es fácilmente legible comprendiendo cada caso. Por ejemplo, que al final de todo el proceso haga una actualización general de los repositorios y cuando arranquemos, tengamos una distribución flamante.

Arrancando Ubuntu 22.04

Hecho todo lo anterior, arranca cualquier equipo con la opción por red y este detectará el servidor de arranque PXE presente en la red local.

¿Te ha sido difícil? Con este servidor configurado y con algunas pruebas previas, tienes un sistema de automatización para instalar imágenes en otros equipos muy interesante con el fin de no olvidar ningún detalle. ¡Ya puedes guardar la "checklist" en el cajón y anota todo en el cloud-init!

El archivo de configuración SSH es una navaja suiza

Daniel M. — Fri, 25 Feb 2022 15:12:51 +0000

El archivo config de ssh permite automatizar el modo de acceso a servidores remotos. Probablemente, accedas a un VPS por un puerto distinto, a otra instancia quieras ir directamente a un directorio distinto o cualquier otra excepción a un acceso estándar sin necesidad de escribir toda la cadena de parámetros.

Por ejemplo, imaginamos que tenemos un servidor en VirtualBox donde tenemos instalado Apache y openssh-server con:

un puerto distinto al establecido por defecto, es decir, diferente al puerto 22,
un usuario distinto al del sistema local.

En él, hemos creado el usuario administracion y queremos acceder vía SSH de manera rápida. ¿Cuál es la opción principal? Escribir

$ ssh -p 2220 administrador@[IP]

Para, luego, teclear la contraseña y tener que acceder a la carpeta /var/www/html. Esto lo podemos automatizar con la configuración ofrecida en la siguiente hoja de ruta:

Generar el par de claves público y privada como hemos detallado en otro tutorial.
Asegurarnos de que tenemos instalado openssh-server en el servidor al que nos queremos conectar. Si no, simplemente teclear

$ sudo apt install openssh-server

en el servidor remoto.

Crear un listado más de parámetros en el archivo config de nuestro equipo local ubicado en ~/.ssh/config:

    # Ubuntu Server 20.04 Virtualbox
    Host ubuntuserver
    Hostname 192.168.1.150
    User administracion
    Port 2220
    RequestTTY yes
    RemoteCommand cd /var/www/html; exec $SHELL
    PreferredAuthentications publickey
    IdentityFile ~/.ssh/privatekeys/ubuntuserver

Por partes:

Host ubuntuserver

nos permite poner nombre para el acceso directo, como veremos a continuación.

Hostname 192.168.1.150

es la IP del servidor. En nuestro caso, hemos configurado en el router que DHCP siempre ofrezca esa IP a la MAC de la tarjeta del servidor.

User administracion

para que acceda con ese usuario. Si no, tomará el nuestro por defecto del host.

Port 2220

Por defecto, ssh intentará acceder al puerto 22. Si el puerto está modificado, hemos de añadir esta opción. En este caso, estaría configurado el 2220.

RequestTTY yes
RemoteCommand cd /var/www/html; exec $SHELL

para que acceda directamente a la carpeta que queremos. La orden puede ser la que quieras, por ejemplo podemos hacer que actualice los repositorios indicando sudo apt update en lugar de cd /var/www/html/

PreferredAuthentications publickey
IdentityFile ~/.ssh/privatekeys/ubuntuserver

para indicar que queremos que acceda por par de claves.

Una vez hecho esto, desde nuestro equipo local accederemos con

ssh ubuntuserver

al servidor remoto y directamente entraremos en

administracion@ubuntuserver:/var/www/html$

Así, accederemos de manera automática a nuestro servidor y a la carpeta en la que trabajamos normalmente, con el $USER deseado y a través del puerto habilitado.

Foto: "Old Railroad switching device" by begemot_dn is licensed under CC BY-NC 2.0.

Instalación de DDEV y despliegue de proyecto Drupal 9 en Ubuntu 20.04

Daniel M. — Fri, 03 Dec 2021 11:08:56 +0000

Instalación de los componentes necesarios para ejecutar DDEV y crear entornos locales de trabajo de PHP. Docker y Docker Compose son requisitos imprescindibles y los instalaremos con la configuración mínima para que funcione DDEV.

El índice de este tutorial es:

Instalación de Docker
Instalación de Docker Compose
Instalación de DDEV y la plantilla de Drupal 9

¿Qué es DDEV?

DDEV es una herramienta de código abierto que facilita la creación de entornos locales de desarrollo PHP. Al montar una instancia en tu servidor, existe la posibilidad de implementar marcos de trabajo de Drupal, WordPress, TYPO3, Backdrop, Magento, Laravel, etc.

Un importante detalle de DDEV es su naturaleza de entorno local de desarrollo, es decir, no es visible en red. Para que sea accesible desde otro equipo, puedes usar ngrok para dotar de URL al entorno.

Web oficial de DDEV
Centro de documentación de DDEV

¿Qué es Docker?

Docker es una plataforma que empaqueta software en unidades llamadas "contenedores" incluyendo los requisitos necesarios para ejecutar un proyecto determinado, como por ejemplo configurar una versión concreta de un servidor de base de datos, bibliotecas, java, etc, distinta a la del sistema operativo que lo contiene. Por eso el uso de la palabra "contenedor", porque encapsula dichos requisitos para un desarrollo óptimo de lo que se ejecute en él.

Aunque esta definición de Docker se pueda asimilar a una virtualización, hay que tener en cuenta que la diferencia principal es el menor consumo de recursos en el uso de contenedores con respecto a máquinas virtuales debido a que, en el primer caso, no es necesario instalar un sistema operativo sobre otro tal como ocurre en las virtualizaciones.

Web oficial de Docker
Centro de documentación de Docker

¿Qué es Docker Compose?

Docker Compose es una herramienta para gestionar varios contenedores a través de un archivo de configuración YAML, permitiendo que, a través de un solo comando, se pueda poner en marcha o eliminar un contenedor.

Documentación sobre Docker Compose

❤️ para @davidjguru , penyaskito, erikaheidi y bhogan.

Instalación de Docker

Actualizamos nuestro sistema para instalar los paquetes más recientes:

$ sudo apt update

Instalamos los requisitos necesarios:

$ sudo apt install build-essential apt-transport-https ca-certificates software-properties-common curl

Agregamos la clave GPG del repositorio oficial de Docker:

$ curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -

y, tras el OK, agregamos el repositorio:

$ sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu focal stable"

En caso de que no actualice repositorios automáticamente, ejecutamos de nuevo:

$ sudo apt update

Con la actualización anterior, comprobamos que no hay ningún error e instalamos Docker desde el repositorio oficial, no desde los originales de Ubuntu:

$ sudo apt install docker-ce

Comprobamos si ha sido instalado y ejecutándose si ejecutamos:

$ sudo systemctl status docker

y obtenemos una salida similar a esta:

[sudo] password for daniel:   
● docker.service - Docker Application Container Engine  
     Loaded: loaded (/lib/systemd/system/docker.service; enabled; vendor preset: enabled)  
     Active: active (running)  since Fri 2021-08-27 19:27:56 CEST; 25min ago  
TriggeredBy: ● docker.socket  
       Docs: https://docs.docker.com  
   Main PID: 736 (dockerd)  
      Tasks: 11  
      Memory: 114.5M  
     CGroup: /system.slice/docker.service  
             └─736 /usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock

Para el cometido de este tutorial sería suficiente, puedes investigar sobre los comandos de Docker ejecutando

$ docker

o accediendo a la documentación oficial dedicada.

Extra

Si al arrancar Docker obtenemos el siguiente error:

Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/  >docker.sock: Get http://%2Fvar%2Frun%2Fdocker.sock/v1.27/containers/json: dial unix /var/run/docker.>sock: connect: permission denied

Otorgamos permisos al user en el grupo docker de la siguiente manera

$ sudo usermod -aG docker $USER && sudo reboot

forzando a reiniciar para aplicar los cambios.

Instalación de Docker Compose

Procedemos a la descarga y configuración de permisos para ejecutar Docker Compose.

Descarga del archivo

A la hora de realizar este tutorial, la última versión corresponde a 2.1.1, comprueba cuál es la más reciente en el listado de lanzamientos en GitHub. Sólamente tendrías que cambiar el número. Las variables $(uname -s) y $(uname -m) eligen tu sistema y arquitectura (32 ó 64 bits), respectivamente.

$ sudo curl -L "https://github.com/docker/compose/releases/download/v2.1.1/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose

Permisos

Ajustamos los permisos para que sea ejecutable:

$ sudo chmod +x /usr/local/bin/docker-compose

Comprobamos la instalación:

$ docker-compose --version

Debemos tener un resultado similar a:

docker-compose version 2.1.1

Así, comprobamos que Docker Compose está correctamente instalado.

Instalación de DDEV y la plantilla de Drupal 9

Dividimos en dos esta parte para mayor claridad.

Instalación de DDEV

Descargamos el script con los comandos para descargar e instalar DDEV:

$ curl -O https://raw.githubusercontent.com/drud/ddev/master/scripts/install_ddev.sh

En el siguiente enlace podemos observar el contenido de este script.

Otorgamos permisos para que el script sea ejecutable:

$ chmod +x install_ddev.sh

y ejecutamos con:

$ ./install_ddev.sh

Durante el proceso, es posible que solicite instalar algunas dependencias o requisitos. Una vez finalizado, ejecuta el siguiente comando para comprobar que está correcto:

$ ddev version

Obtenemos una salida similar a esta, dependiendo de las versiones y la arquitectura de nuestro sistema:

ITEM            VALUE                                                
 DDEV version    v1.18.1                                              
 architecture    amd64                                                
 db              drud/ddev-dbserver-mariadb-10.3:20211017_mysql_arm64 
 dba             phpmyadmin:5                                         
 ddev-ssh-agent  drud/ddev-ssh-agent:v1.18.0                          
 docker          20.10.11                                             
 docker-compose  v2.1.1                                               
 mutagen         0.12.0                                               
 os              linux                                                
 router          drud/ddev-router:v1.18.0                             
 web             drud/ddev-webserver:v1.18.1

A través de

$ ddev

listamos los comandos de ddev. Puedes visitar el centro de documentación para más detalles.

Nota: Hasta este punto, cualquier instalación con DDEV será igual, por lo que si queremos instalar otras plantillas como Magento, en lugar de Drupal, toda la tarea realizada hasta ahora no es necesario repetirla.

Instalación de la plantilla Drupal 9

Creamos y accedemos a la carpeta donde albergaremos el proyecto:

$ mkdir miproyecto && cd miproyecto

Dentro de la carpeta raíz, creamos la estructura de directorios de Drupal 9. Ambas opciones ofrecen el mismo resultado, sirviendo su observación para conocer mejor el funcionamiento de DDEV.

Opción 1

Al escribir en el terminal

$ ddev config

Nos preguntará la ruta donde queremos guardarla y el tipo de plantilla. En este caso, elegiremos Drupal 9. Marco en negrita lo que he introducido. El resto es la salida de la instalación:

daniel@ubuntuserver:~/miproyecto$ ddev config  
Creating a new ddev project config in the current directory (/home/daniel/miproyecto)  
Once completed, your configuration will be written to /home/daniel/miproyecto/.ddev/config.yaml  

Project name (miproyecto): Drupalea          

The docroot is the directory from which your site is served.  
This is a relative path from your project root at /home/daniel/miproyecto  
You may leave this value blank if your site files are in the project root   
Docroot Location (current directory):  [He dejado en blanco]   
Found a php codebase at /home/daniel/miproyecto.  
Project Type [backdrop, drupal6, drupal7, drupal8, drupal9, laravel, magento, magento2, php, shopware6, typo3, wordpress] (php): drupal9  
Ensuring write permissions for Drupalea  
No settings.php file exists, creating one  
Existing settings.php file includes settings.ddev.php  
Configuration complete. You may now run 'ddev start'.

Devolviéndonos el terminal. Importante indicar que Docroot location lo he dejado en blanco para que la estructura se cree, por defecto, en la carpeta raíz y no sea, por ejemplo, un subdirectorio.

Opción 2

De antemano, podemos incluir las dos opciones incluidas arriba a través de parámetros:

$ ddev config --docroot=web --create-docroot --project-type=drupal9

Obtenemos la siguiente salida:

Creating a new ddev project config in the current directory (/home/daniel/miproyecto)  
Once completed, your configuration will be written to /home/daniel/miproyecto/.ddev/config.yaml  

Created docroot at /home/daniel/miproyecto/web  
You have specified a project type of drupal9 but no project of that type is found in /home/daniel/miproyecto/web  
Ensuring write permissions for miproyecto   
No settings.php file exists, creating one  
Existing settings.php file includes settings.ddev.php  
Configuration complete. You may now run 'ddev start'.

Por ahora, no es necesario ejecutar ddev start.

Descarga de la plantilla Drupal 9 a través de Composer

Una vez tenemos la estructura, y sin salirnos de la carpeta raíz, ejecutamos:

$ yes | ddev composer create drupal/recommended-project

El "yes" del inicio sirve para automatizar el paso en el que solicita si puede seguir para reescribir la estructura creada en el anterior paso. Al modificar parte del árbol de directorios creado con ddev config, es normal que solicite permisos para seguir.

Nota: No hay que confundir "Docker Compose", descrito en este tutorial, con "Composer", el administrador para proyectos PHP con el que instalaremos los paquetes de Drupal 9.

Instalamos Drush, una aplicación basada en shell que se utiliza para controlar, manipular y administrar los sitios web de Drupal, además de otros módulos básicos para este CMS como admin_toolbar y devel que añadirán funcionalidades extra de navegación.

$ ddev composer require drush/drush drupal/admin_toolbar drupal/devel

Obteniendo una salida similar a esta:

Using version ^10.6 for drush/drush  
./composer.json has been created  
Running composer update drush/drush  
Loading composer repositories with package information  
Updating dependencies  
Lock file operations: 46 installs, 0 updates, 0 removals  
&nbsp;&nbsp;-Locking chi-teck/drupal-code-generator (1.33.1)  
 ...  
Writing lock file  
Installing dependencies from lock file (including require-dev)  
Package operations: 46 installs, 0 updates, 0 removals  
&nbsp;&nbsp;-Downloading ... Extracting archive  
&nbsp;&nbsp;-Installing ...: Extracting archive  
...  
12 package suggestions were added by new dependencies, use `composer suggest` to see details.  
Package container-interop/container-interop is abandoned, you should avoid using it. Use psr/container instead.  
Generating autoload files  
18 packages you are using are looking for funding.  
Use the `composer fund` command to find out more!

Nota: Los puntos suspensivos representa la larga lista de paquetes que se van descargando e instalando automáticamente.

Sobre este tipo de instalación via línea de comandos, tienes más información en la web oficial de Drupal dedicado a esta materia.

Antes de lanzar la instancia, configuramos la base de datos:

$ ddev exec drush si --site-name=Drupaleame --account-name=admin --account-pass=password -y

Como último paso antes de obtener una instancia de Drupal 9, lanzamos lo instalado:

$ ddev start

Obteniendo una salida similar a:

Starting Drupalea... 
Building ddev-ssh-agent 
Recreating ddev-ssh-agent ...  
Recreating ddev-ssh-agent ... done 
ssh-agent container is running: If you want to add authentication to the ssh-agent container, run 'ddev auth ssh' to enable your keys. 
Running   Command=ip address show dev docker0
Building db 
Building web 
Creating ddev-Drupalea-db ...  
Creating ddev-Drupalea-db ... done 
Creating ddev-Drupalea-dba ...  
Creating ddev-Drupalea-web ...  
Creating ddev-Drupalea-web ... done 
Creating ddev-Drupalea-dba ... done 
Creating ddev-router ...  
Creating ddev-router ... done 
Ensuring write permissions for Drupalea 
Existing settings.php file includes settings.ddev.php 
Ensuring write permissions for Drupalea 
Successfully started Drupalea 
Project can be reached at https://drupalea.ddev.site https://127.0.0.1:49154

Nota: El puerto puede ser diferente.

Opción 1, sistema con entorno gráfico

En caso de que el entorno local donde hayamos instalado DDEV tenga escritorio tipo GNOME, KDE, XFCE, etc, podemos ejecutar lo siguiente desde terminal para lanzar a nuestro navegador el configurador de Drupal:

$ ddev launch

Opción 2, sistema sin entorno gráfico

Si hemos instalado DDEV en un servidor sin escritorio y lanzamos ddev launch, obtenemos el siguiente error

/home/daniel/miproyecto/.ddev/commands/host/launch: line 61: xdg-open: command not found  
Failed to run launch ; error=exit status 127

Como es lógico, al no tener entorno gráfico, xdg-open no se encuentra instalado en el sistema ni objetivo sobre el que ejecutar, que sería un navegador tipo Mozilla Firefox.

En este caso, probamos el navegador lynx de la siguiente manera:

Instalamos el navegador desde repositorios de Ubuntu:

$ sudo apt install lynx

y probamos

$lynx drupalea.ddev.site

Veremos, en el terminal, el texto de una página de configuración de Drupal.

Welcome to Example-Drupal |Example-Drupal (p1 of 2)

   #alternate

   Skip to main content

User account menu

   Show — User account menu Hide — User account menu

     * Log in

   Home

   Drupaleame

Main navigation

   Show — Main navigation Hide — Main navigation

     * Home

Welcome to Drupaleame

   No front page content has been created yet.

   Follow the User Guide to start building your site.

   Subscribe to

A partir de ahora, con Docker, Docker Compose y DDEV ya presentes en nuestro equipo, podemos probar otras plantillas como WordPress o Magento a través de DDEV.

Foto: Containers by tsuna72 is licensed with CC BY 2.0

Gestión ordenada de claves pública y privada para acceso por SSH

Daniel M. — Fri, 03 Dec 2021 10:12:35 +0000

¿Cómo crear y gestionar claves SSH de manera ordenada? (Versión GNU/Linux)

Tras el anuncio en julio de 2020 en el que GitHub anunciaba la desactivación del acceso a los repositorios mediante user/pass, la mejor opción y más segura es usar claves SSH. Esta forma de acceso y autenticación no es nueva, seguramente tengas más de una clave ya configurada con cifrado antiguo y guardadas de aquella manera. ¿Qué mejor momento que ordenarlas, eliminar las que no uses y actualizarlas? En este breve tutorial vamos a crear nuevas claves con cifrado ed22519 para 3 plataformas: GitLab, GitHub y Bitbucket.

Renovación de pares de claves al cifrado ed25519 y ordenación para autenticación en múltiples plataformas.

Importante:Importante: si no tienes ninguna clave creada, ve directamente al punto 2. El 1 está dedicado a mostrar cómo podemos tener de desordenado el acceso a servidores remotos mediante claves si ya se han creado anteriormente.

1. Localizar las claves y mostrar el directorio

Dentro de nuestra carpeta /home/$USER, existen dos tipos de archivos, los que están sin ocultar que se visualizan con normalidad y los ocultos que tienen un punto delante. Para poder listar los segundos, debemos añadir la opción -a a la orden:

Listado de archivos sin ocultar

ls -l

Listado de archivos sin ocultar y ocultos

ls -la

Si observamos entre las carpetas ocultas, tendremos .ssh que será en la que organizaremos las claves públicas y privadas.

$ cd ~/.ssh && ls -l

Importante: Este punto, como he comentado anteriormente, es orientativo, solo sirve para comprobar si tenemos claves sin usar y/o antiguas ya creadas.

Probablemente, tengas una estructura similar a esta

-rw-rw-r-- 1 [USER] [GROUP]  370 jul 28 2016 clavessh
-rw-rw-r-- 1 [USER] [GROUP]  370 jul 28 2016 clavessh.pub
-rw-rw-r-- 1 [USER] [GROUP]  378 jun 21 2018 clave1.pub
-rw-rw-r-- 1 [USER] [GROUP]  380 jun 21 2018 clave1
-rw-rw-r-- 1 [USER] [GROUP]  370 jul 28 17:37 claveprivada.pub
-rw------- 1 [USER] [GROUP] 5762 jul 28 17:38 known_hosts
-rw------- 1 [USER] [GROUP] 3770 jun 18 10:56 known_hosts.old

Sabes que el par de claves clavessh accede a algo pero no a qué, y mucho menos clave1. Por otro lado, claveprivada.pub, que no tiene sentido, tiene perdida su parte privada. En definitiva, un lío que es mejor eliminar.

2. La casa por la ventana y muebles nuevos, aplicamos algoritmo de cifrado ed22519

Sin posibilidad de recordar qué tipo de cifrado tenemos (lo veremos posteriormente), es posible que se trate de RSA con una longitud de bits entre 1024 y 2048. Introducido en la versión 6.5 (2014) de OpenSSH, ed22519 presenta mejor robustez y, además, está recomendado por plataformas como GitLab.

GitLab and SSH keys

2.1 Eliminamos los archivos que tenemos desperdigados en la carpeta .ssh

Procedemos a identificar qué archivos son. Presumiblemente, los que tienen la extensión .pub son la par pública y los que no tienen extensión, la privada. Recuerda que hemos de estar en la carpeta oculta .ssh tal como hicimos en el primer comando, es decir

$ cd ~/.ssh

Realizamos la siguiente operación en uno de los archivos arriba expuestos

$ cat clavessh

mostrando lo siguiente

-----BEGIN OPENSSH PRIVATE KEY-----
[Filas de caracteres aleatorios]
-----END OPENSSH PRIVATE KEY-----

Nos aseguramos de que este archivo sí es una clave privada. Si realizamos

$ cat ~/.ssh/clavessh.pub

nos muestra una información con la siguiente estructura

ssh-rsa [caracteres aleatorios] -C [e-mail]

Ya hemos descubierto que se trata de un algoritmo RSA. Visto esto, e identificando cuáles son los archivos de claves, los eliminaremos y crearemos nuevos con el siguiente comando

$ rm clavessh* clave1 claveprivada*

o bien, teniendo en cuenta que todos empiezan por la cadena "clave"

$ rm clave*

2.2 Crear carpetas para las claves privadas y públicas

Con el objetivo de tener las claves ordenadas, creamos dos carpetas dentro de .ssh

$ mkdir clavesprivadas

$ mkdir clavespublicas

3. Creación de claves

Si nos hemos movido, volvemos a la carpeta .ssh

$ cd ~/.ssh

Generamos las claves con

$ ssh-keygen -t ed25519 -C "[inserta tu e-mail]"

Y obtenemos lo siguiente.

Generating public/private ed25519 key pair.

En la siguiente pregunta, escribe, por ejemplo, la plataforma en la que vas a usar esta clave. En este caso, he indicado gitlab

Enter file in which to save the key (/home/[USER]/.ssh/id_ed25519): gitlab

Puedes incluir, o no, una capa extra que sería la contraseña:

Enter passphrase (empty for no passphrase): 
Enter same passphrase again:

Ya tenemos los datos guardados en la carpeta .ssh, dos archivos llamados gitlab (clave privada) y gitlab.pub (clave pública)

Your identification has been saved in gitlab
Your public key has been saved in gitlab.pub
The key fingerprint is:
SHA256:[Códigos aleatorios] [el e-mail que incluiste]
The key's randomart image is:
+--[ED25519 256]--+
|            * *O=|
|         E + *=**|
|        . = .E==*|
|         + . ..+*|
|        s o   .o*|
|       . o + .  *|
|        . . = o.+|
|             = +o|
|              =++|
+----[SHA256]-----+

Si listamos la carpeta .ssh, nos encontramos con los dos archivos recientemente creados y las carpetas donde guardaremos las claves

$ ls -l ~/.ssh
total 24
-rw-rw-r-- 1 [USER] [GROUP]  411 jul 29 12:00 gitlab
-rw-rw-r-- 1 [USER] [GROUP]   99 jul 29 12:00 gitlab.pub
-rw------- 1 [USER] [GROUP] 5762 jul 28 17:38 known_hosts
-rw------- 1 [USER] [GROUP] 3770 jun 18 10:56 known_hosts.old
drwxrwxr-x 2 [USER] [GROUP] 4096 jul 29 11:55 clavesprivadas
drwxrwxr-x 2 [USER] [GROUP] 4096 jul 29 11:55 clavespublicas

De la misma manera, podemos crear nuevas claves para cualquier plataforma. Como recordatorio, no es obligatorio poner el nombre de la plataforma, pero así quedaría mejor organizado.

3.1 Agregar clave ssh al ssh-agent

Iniciamos el agente ssh en un segundo plano

$ eval "$(ssh-agent -s)"

Arrojando un PID (Process ID) garantizando que ha sido arrancado correctamente

Agent pid XXXXX

Siendo XXXXX un número diferente cada vez. Agregamos la clave privada al agente SSH

$ ssh-add ~/.ssh/gitlab

Repetimos este último paso de agregar la clave privada con el resto que hayamos creado.

4. Guardado de claves

Simplemente, se trata de mover cada clave a su carpeta

$ mv gitlab clavesprivadas/

$ mv gitlab.pub clavespublicas/

Si hemos creado otras claves, realizamos el mismo proceso modificando el nombre del archivo en la orden de arriba.

5. Copia de clave pública en plataformas

Para que GitLab, en este caso, nos reconozca la clave, hay que agregar la clave en la sección correspondiente. Como primer paso, hay que acceder a la carpeta donde está almacenada

$ cd clavespublicas

vemos el contenido

$ cat gitlab.pub

Nos aparecerá una línea similar a esta

ssh-rsa [caracteres aleatorios] [e-mail]

Seleccionamos la línea completa y copiamos su contenido.

5.1 Registro en plataforma

Siguiendo con el ejemplo de GitLab, seguimos los pasos para llegar al lugar donde se registran tras acceder a nuestro perfil

(Opción 1) Acceso directo a la sección Claves SSH de Preferencias
(Opción 2) Esquina superior derecha Preferences -> Columna izquierda Claves SSH

Una vez dentro

En "Clave", copiamos el contenido de nuestra clave pública. Asegúrate que empieza por ssh-ed25519 y que termine con el correo electrónico que anotamos cuando la creamos.
En el cajón "Título", elige una definición descriptiva. Por ejemplo, el equipo que usa esa clave.
Como medida opcional de seguridad, puedes agregar una fecha de caducidad.

Ya tendríamos la clave registrada. La siguiente tarea consistirá en probar que funciona. Vamos al terminal y, dentro de la subcarpeta clavesprivadas de .ssh, escribimos

$ ssh -T -i gitlab git@gitlab.com

Y obtendrías el siguiente mensaje en caso de haber configurado correctamente la clave SSH

Welcome to GitLab, @[GitLab_User]!

Si quieres ver cómo funciona el test de conexión o mirar qué puede haber fallado (ruta mal escrita, archivo desubicado,...), puedes probar añadiendo el parámetro -v de "verbose"

$ ssh -T -v -i gitlab git@gitlab.com

Tras mostrar por pantalla las conexiones establecidas, las 4 últimas líneas serían

Welcome to GitLab, @[GitLab_User]!
debug1: channel 0: free: client-session, nchannels 1
Transferred: sent 2084, received 2400 bytes, in 0.6 seconds
Bytes per second: sent 3568.5, received 4109.6

6. Creación del archivo config de SSH

Una vez guardadas las claves en carpetas, creamos el archivo de configuración que servirá para dos objetivos básicos:

Identificar las claves con la plataforma en donde las estamos usando.
Crear un índice para identificar las que no estamos usando y, por seguridad, podemos borrar.

Para crear el archivo, debemos llamarlo "config" y ubicarlo dentro de la carpeta .ssh. Con el comando nano creamos y abrimos directamente el nuevo archivo:

$ nano ~/.ssh/config

Una vez que nos encontramos con el archivo recién creado, identificamos cada clave de la siguiente manera:

# Texto informativo que identifique cada plataforma
Host ejemplo.ltd
HostName ejemplo.ltf
PreferredAuthentications publickey
IdentityFile ~/.ssh/clavesprivadas/claveprivada

Aplicando el ejemplo de GitLab, quedaría así:

# GitLab
Host gitlab.com
HostName gitlab.com
PreferredAuthentications publickey
IdentityFile ~/.ssh/clavesprivadas/gitlab

Podemos crear en el mismo archivo, manteniendo la misma estructura, todas las claves privadas. A continuación, un supuesto caso de que tuviésemos las claves en GitLab, GitHub y Bitbucket:

# GitHub
Host github.com
HostName github.com
PreferredAuthentications publickey
IdentityFile ~/.ssh/clavesprivadas/github

# GitLab
Host gitlab.com
HostName gitlab.com
PreferredAuthentications publickey
IdentityFile ~/.ssh/clavesprivadas/gitlab

# Bitbucket
Host bitbucket.org
HostName bitbucket.org
PreferredAuthentications publickey
IdentityFile ~/.ssh/clavesprivadas/bitbucket

Si queremos probar la conexión, copiamos el siguiente comando en el caso de GitLab.

$ ssh -T -v -i gitlab git@gitlab.com

Teniendo en cuenta que hemos añadido la opción verbose con -v, podemos observar que entre las líneas de respuesta encontramos un fragmento similar a este:

debug1: Trying private key: /home/[USER]/.ssh/clavesprivadas/gitlab
debug1: Authentication succeeded (publickey).
Authenticated to gitlab.com ([IP]:[PUERTO (normalmente, 22)]).

Con este resultado, comprobamos que la conexión de la clave privada con nuestro repositorio es exitosa.

Extra

Actualizar URI de repositorio de https a SSH

¿Qué ocurre si ya teníamos un repositorio que se identificase a través de https y lo que queremos es a través de las claves? Probablemente, una vez configuradas las claves, hayas intentado realizar un commit y siga solicitando user/pass. Para ello, debemos realizar, dentro de la carpeta del repositorio, el siguiente comando:

$ git remote set-url git@gitlab.com:USERNAME/REPOSITORY.git

Más información en How to change Git Remote Origin

Protección extra de la carpeta de claves privadas

Si realizamos un listado de la carpeta con el siguiente comando:

$ ls ~/.ssh/

Obtenemos un resultado similar:

total 24
-rw------- 1 [USER] [GROUP] 5762 jul 28 17:38 known_hosts
-rw------- 1 [USER] [GROUP] 3770 jun 18 10:56 known_hosts.old
drwxrwxr-x 2 [USER] [GROUP] 4096 jul 29 11:55 clavesprivadas
drwxrwxr-x 2 [USER] [GROUP] 4096 jul 29 11:55 clavespublicas

Normalmente, los archivos tienen permisos 644, es decir:

6 como permisos de lectura y escritura con nuestro propio user.
4 como permisos de lectura para quienes estén en el mismo grupo asociado.
4 como permisos de lectura para otras personas que estén en nuestro sistema.

Y los directorios, 755. Para profundizar en este tema, recomiendo este enlace de atareao Propietarios y permisos.

¿Qué podemos hacer al respecto? Cambiar los permisos a 600 para que nadie puede acceder ni leer los archivos de las claves privadas si no es con nuestro propio user.

$ chmod 700 ~/.ssh/clavesprivadas

Así, si volvemos a hacer ls -l obtenemos el mismo listado pero con una ligera diferencia:

total 24
-rw------- 1 [USER] [GROUP] 5762 jul 28 17:38 known_hosts
-rw------- 1 [USER] [GROUP] 3770 jun 18 10:56 known_hosts.old
drwx------ 2 [USER] [GROUP] 4096 jul 29 11:55 clavesprivadas
drwxrwxr-x 2 [USER] [GROUP] 4096 jul 29 11:55 clavespublicas

En la línea del directorio clavesprivadas han desaparecido los permisos para el mismo grupo y "otros". De esta manera, una persona que no sea yo no tiene acceso ni permisos de lectura de una carpeta con un contenido tan sensible como es la que contiene nuestras claves privadas.

Foto: "Engranaje" por J4R está licenciada con CC BY-SA 2.0.