I have Ubuntu server on Google Cloud/Compute Engine that works with no issues. I can ssh into it from command line or I ssh into it from the Google Cloud dashboard console.
When I take a snapshot of it to clone the server, I can not ssh into the new clone. The ssh daemon does not seem to be listening. I can not even ssh into it from the Google Cloud dashboard.
Does anyone know why?
From serial console(Note- I edited the sha256 in the paste):
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.
If the new instance is created from a snapshot of the source instance, sshd configuration should be no different on the new instance generated from the snapshot than that of the source instance.
When you attempt to SSH from the Cloud Shell what is the error message you are receiving?
When you take a snapshot, it is a snapshot of the disk, and doesn't include any information about the other aspects of the source machine.
Is it possible that the new instance you are creating from the snapshot hasn't been assigned the same network tags as the source instance (which may prevent port 22 access to the new instance)? I think this is definitely worth checking.
Also, ensure you have assigned the new machine an external IP address.
EDIT:
I am added some additional information in relation to the posters updated information regarding an invalid fstab entry affecting the boot of the instance (and thus affecting SSH access to the instance).
There is some useful information here regarding adding the [NOFAIL_OPTION] to the fstab entry, which is a variable that specifies what the operating system should do if it cannot mount the persistent disk at boot time. This can be used to prevent boot issue related to invalid fstab entries.
The issue was that I had a attached disk on the original instance.
The solution was to comment out the mounting of the attached disk in
/etc/fstab.A normal linux system would continue to boot and run ssh if a non root mount point was not mounted. No error messages in the serial console indicated this ether.
Although Google's cloud is still my favorite for cloud, this is a major fail on their part.