Tengo un servidor Ubuntu en Google Cloud/Compute Engine que funciona sin problemas. Puedo acceder a él desde la línea de comandos o desde la consola del panel de Google Cloud.
Cuando tomo una instantánea para clonar el servidor, no puedo acceder al nuevo clon mediante ssh. El demonio ssh no parece estar escuchando. Ni siquiera puedo acceder a él desde el panel de Google Cloud.
¿Alguien sabe por qué?
Desde la consola serie (Nota: edité el sha256 en el archivo pegado):
Mar 20 20:16:19 qa-for-work cloud-init[1042]: Generating public/private ed25519 key pair.
Mar 20 20:16:19 qa-for-work cloud-init[1042]: Your identification has been saved in /etc/ssh/ssh_host_ed25519_key.
cloud-init[1042]: Your identification has been saved in /etc/ssh/ssh_host_ed25519_key.
Mar 20 20:16:20 qa-for-work cloud-init[1042]: Your public key has been saved in /etc/ssh/ssh_host_ed25519_key.pub.
[ 110.667373] cloud-init[1042]: Your public key has been saved in /etc/ssh/ssh_host_ed25519_key.pub.
Mar 20 20:16:20 qa-for-work cloud-init[1042]: The key fingerprint is:
[ 110.667475] cloud-init[1042]: The key fingerprint is:
Mar 20 20:16:20 qa-for-work cloud-init[1042]: SHA256:u6ros 4MQtfpO5GM root@qa-for-work
[ 110.667560] cloud-init[1042]: SHA256:u6ros 1GtaVy4MQtfpO5GM root@qa-for-work
Mar 20 20:16:20 qa-for-work cloud-init[1042]: The key's randomart image is:
[ 110.667644] cloud-init[1042]: The key's randomart image is:
Mar 20 20:16:20 qa-for-work cloud-init[1042]: +--[ED25519 256]--+
[ 110.667775] cloud-init[1042]: +--[ED25519 256]--+
Mar 20 20:16:20 qa-for-work cloud-init[1042]: | o*o..=+o... |
[ 110.667864] cloud-init[1042]: | o*o..=+o... |
Mar 20 20:16:20 qa-for-work cloud-init[1042]: | o.o.o.+... |
[ 110.667939] cloud-init[1042]: | o.o.o.+... |
Mar 20 20:16:20 qa-for-work cloud-init[1042]: | o . ...o . |
[ 110.668037] cloud-init[1042]: | o . ...o . |
Mar 20 20:16:20 qa-for-work cloud-init[1042]: | = . .. + |
[ 110.668116] cloud-init[1042]: | = . .. + |
Mar 20 20:16:20 qa-for-work cloud-init[1042]: | + = o S . |
[ 110.668192] cloud-init[1042]: | + = o S . |
Mar 20 20:16:20 qa-for-work cloud-init[1042]: | o + o + . |
[ 110.668275] cloud-init[1042]: | o + o + . |
Mar 20 20:16:20 qa-for-work cloud-init[1042]: |o + o E |
[ 110.668349] cloud-init[1042]: |o + o E |
Mar 20 20:16:20 qa-for-work cloud-init[1042]: |.*.+ . + o |
[ 110.668503] cloud-init[1042]: |.*.+ . + o |
Mar 20 20:16:20 qa-for-work cloud-init[1042]: |ooB+o...o |
[ 110.668596] cloud-init[1042]: |ooB+o...o |
Mar 20 20:16:20 qa-for-work systemd[1]: Started Initial cloud-init job (metadata service crawler).
Mar 20 20:16:20 qa-for-work cloud-init[1042]: +----[SHA256]-----+
[ 110.668946] cloud-init[1042]: +----[SHA256]-----+
Mar 20 20:16:20 qa-for-work ntpdate[1023]: adjust time server 169.254.169.254 offset 0.361638 sec
Mar 20 20:16:20 qa-for-work systemd[1]: Reached target Network is Online.
Mar 20 20:16:20 qa-for-work systemd[1]: Reached target Cloud-config availability.
Mar 20 20:16:20 qa-for-work systemd[1]: Startup finished in 7.356s (kernel) + 1min 42.350s (userspace) = 1min 49.706s.
Respuesta1
El problema era que tenía un disco adjunto en la instancia original.
La solución fue comentar el montaje del disco adjunto en formato /etc/fstab.
Un sistema Linux normal continuaría arrancando y ejecutando ssh si no se montó un punto de montaje que no sea raíz. Ningún mensaje de error en la consola serie indicó este éter.
Aunque la nube de Google sigue siendo mi favorita, este es un gran fracaso de su parte.
Respuesta2
Si la nueva instancia se crea a partir de una instantánea de la instancia de origen, la configuración de sshd no debe ser diferente en la nueva instancia generada a partir de la instantánea que la de la instancia de origen.
Cuando intenta realizar SSH desde Cloud Shell, ¿cuál es el mensaje de error que recibe?
$ gcloud compute ssh INSTANCE_NAME
Cuando toma una instantánea, es una instantánea del disco y no incluye ninguna información sobre los otros aspectos de la máquina de origen.
¿Es posible que a la nueva instancia que está creando a partir de la instantánea no se le hayan asignado las mismas etiquetas de red que la instancia de origen (lo que puede impedir el acceso al puerto 22 a la nueva instancia)? Creo que definitivamente vale la pena comprobarlo.
Además, asegúrese de haber asignado a la nueva máquina una dirección IP externa.
EDITAR:
Se me agregó información adicional en relación con la información actualizada de los carteles sobre una entrada fstab no válida que afecta el arranque de la instancia (y, por lo tanto, afecta el acceso SSH a la instancia).
Hay alguna información útil.aquícon respecto a agregar [NOFAIL_OPTION] a la entrada fstab, que es una variable que especifica lo que debe hacer el sistema operativo si no puede montar el disco persistente en el momento del arranque. Esto se puede utilizar para evitar problemas de arranque relacionados con entradas fstab no válidas.