[OCI] Recuperación del acceso de un IaaS

Vamos a ver como podríamos recuperar de forma fácil el acceso a un IaaS al que se ha perdido el authorized_keys del usuario opc.

Antes de entrar en faena, vamos hacer un pequeño resumen de lo que es cada punto:

• authorized_keys: fichero que contiene las claves públicas para poder acceder a un servidor sin contraseña.

• opc “Oracle Public Cloud”: cuenta del administrador del sistema. Todos los recursos que tengamos en nuestra tenancy, a la hora de acceder lo haremos con este usuario.

Accedemos a nuestra máquina y listamos el contenido de /home/opc/.ssh.

[opc@zdm-host .ssh]$ ls -lac
total 16
drwx------. 2 opc opc   75 Jul 13 14:24 .
drwx------. 5 opc opc 4096 Oct 18  2023 ..
-rw-------. 1 opc opc  400 Oct 18  2023 authorized_keys
-rw-rw-r--. 1 opc opc  514 Oct 18  2023 authorized_keys.zip
-rw-r--r--. 1 opc opc  203 Oct 30  2023 known_hosts

Ahí podemos ver diferentes archivos, ninguna clave pública ni privada, solo el authorized_keys, un backup del mismo y el known_hosts. Procedemos a eliminar el authorized_keys e intentamos loguearnos de nuevo:

¡Upps! Efectivamente, hemos perdido el acceso a nuestra máquina.

Esto es algo que nos puede pasar en el día a día, alguien borro sin querer el authorized_keys o bien que se ha corrompido o simplemente que modificaron los permisos del fichero. En este caso hay un backup, pero en el caso que no lo tengamos, tendríamos que generar nosotros la clave.

Para ambos problemas, la manera de solucionarla es idéntica.

Para poder solucionarlo tendremos que hacer un detach de nuestro boot volumen para adjuntarlo en otro IaaS.

Así que… let's get down to business!

Primer paso es detener la instancia afectada:

Una vez detenida, procedemos a realizar el detach del boot volumen. Para ello vamos a la sección de “Storage” y ahí veremos nuestro boot volumen.

Una vez que la operación ha terminado, el estado del boot volumen pasará a “Detached”

Antes de pasar al siguiente punto, recomiendo copiar el OCID:

Vamos a la IaaS donde vamos a realizar la recuperación del mismo. El primer paso que tenemos que hacer es adjuntar ahí nuestro boot volume. Para hacerlo iríamos a la sección de “Storage” y de ahí a “Attach block Volume”

En esta nueva ventana que aparece nos pedirá una serie de información acerca del boot volume. Copiamos ahí el OCID que habíamos copiado previamente e indicamos que queremos tener acceso read/write

Una vez finalizada podremos ver nuestro boot volume se ha adjuntado de manera correcta.

Si accedemos a la máquina, podemos ver el volumen que hemos adjuntado (/dev/sdb3):

[root@test ~]# fdisk -l /dev/sdb
Disk /dev/sdb: 200 GiB, 214748364800 bytes, 419430400 sectors
Disk model: BlockVolume
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 1048576 bytes
Disklabel type: gpt
Disk identifier: AEAC51C9-5D28-48CB-82FF-1B7312827FEB

Device        Start       End   Sectors   Size Type
/dev/sdb1      2048    411647    409600   200M EFI System
/dev/sdb2    411648  17188863  16777216     8G Linux swap
/dev/sdb3  17188864 419430365 402241502 191.8G Microsoft basic data

El siguiente paso es marcar como disponible para el S.O nuevo boot volumen por medio del comando mount:

[root@test ~]# mount -o nouuid /dev/sdb3 /mnt
[root@test ~]# df -h
Filesystem                  Size  Used Avail Use% Mounted on
devtmpfs                    4.0M     0  4.0M   0% /dev
tmpfs                       7.6G     0  7.6G   0% /dev/shm
tmpfs                       3.1G  8.7M  3.1G   1% /run
efivarfs                    256K   17K  235K   7% /sys/firmware/efi/efivars
/dev/mapper/ocivolume-root   30G  9.4G   21G  32% /
/dev/sda2                   2.0G  412M  1.6G  21% /boot
/dev/mapper/ocivolume-oled   15G  178M   15G   2% /var/oled
/dev/sda1                   100M  6.3M   94M   7% /boot/efi
tmpfs                       1.6G     0  1.6G   0% /run/user/989
tmpfs                       1.6G     0  1.6G   0% /run/user/1000
/dev/sdb3                   192G   13G  179G   7% /mnt

Accedemos a /mnt/home/opc/.ssh para recuperar nuestro authorized_keys.

[root@test ~]# cd /mnt/home/opc/.ssh
[root@test .ssh]# unzip authorized_keys.zip && chown opc:opc authorized_keys
Archive:  authorized_keys.zip
[root@test .ssh]# ls -lac
total 16
drwx------. 2 opc opc   75 Jul 13 15:38 .
drwx------. 5 opc opc 4096 Oct 18  2023 ..
-rw-------. 1 opc opc  400 Jul 13 15:38 authorized_keys
-rw-rw-r--. 1 opc opc  514 Jul 13 14:24 authorized_keys.zip
-rw-r--r--. 1 opc opc  203 Oct 30  2023 known_hosts

Accedemos, realizamos unzip y cambiamos el propietario/grupo del fichero.

Desmontamos /mnt y comprobamos que ya no se encuentra accesible, para poder realizar detach de nuevo:

[root@test ~]# umount /mnt
[root@test ~]# df -h
Filesystem                  Size  Used Avail Use% Mounted on
devtmpfs                    4.0M     0  4.0M   0% /dev
tmpfs                       7.6G     0  7.6G   0% /dev/shm
tmpfs                       3.1G  8.7M  3.1G   1% /run
efivarfs                    256K   17K  235K   7% /sys/firmware/efi/efivars
/dev/mapper/ocivolume-root   30G  9.4G   21G  32% /
/dev/sda2                   2.0G  412M  1.6G  21% /boot
/dev/mapper/ocivolume-oled   15G  178M   15G   2% /var/oled
/dev/sda1                   100M  6.3M   94M   7% /boot/efi
tmpfs                       1.6G     0  1.6G   0% /run/user/989
tmpfs                       1.6G     0  1.6G   0% /run/user/1000

Perfecto, vamos adjuntar de nuevo el boot volumen en la IaaS que habíamos perdido acceso:

• Realizamos detaching

• Una vez que la operación ha terminado correctamente, realizamos attach de nuevo en el IaaS que habíamos perdido acceso

Una vez terminada la operación, arrancamos de nuevo el entorno de nuevo y verificamos que hemos recuperado el acceso:

Using username "opc".
Authenticating with public key "imported-openssh-key"
Last login: Sun Jul 13 14:06:47 2025 from 10.98.140.36
[opc@zdm-host ~]$

Perfecto, tenemos acceso de nuevo. ¡Espero que os sirva!