There are many reasons why a Compute Engine instance might refuse SSH connections. Some common causes of SSH connection issues are as follows:
- OS Login is enabled on the instance. You cannot use both metadata-based SSH keys and OS Login to connect to an instance. If OS Login is enabled, then connecting with metadata-based SSH keys is disabled because OS Login does not store SSH keys in authorized keys files.
- OS Login is not enabled.
When OS Login is not enabled, Google manages the authorized keys file for new
user accounts based on SSH keys in metadata. A Compute Engine instance
no longer accepts SSH connections using the SSH keys configured as part of
your user account.
- All public images have SSH password login disabled.
- The accounts daemon stores a file in the guest to preserve state for the user accounts managed by Google.
- When you remove all the SSH keys for the user account from metadata, the authorized keys file for a Google-managed user account is deleted.
- The accounts daemon doesn't modify user accounts that aren't managed by Google.
- The instance has a full disk. Check your disk space and clean it up as needed.
sshddaemon is not configured properly. Review the user guide for your operating system to ensure that your ssh_d file is set up correctly.
This topic describes ways to help troubleshoot and resolve some of the most common SSH issues.
You can run most of your troubleshooting steps from your local workstation. To use a local Linux or Windows workstation to troubleshoot a VM instance, you must first prepare the workstation.
Prepare your workstation with the following steps:
You might not be able to SSH to a VM instance because of connectivity issues linked to firewalls, network connection, or the user account. Follow the steps in this section to identify any connectivity issues.
Check your firewall rules
Compute Engine provisions each project with a default set of firewall
rules that permit SSH traffic. If you are unable to access your instance, use
gcloud compute command-line tool to
check your list of firewalls and
ensure that the
default-allow-ssh rule is present.
On your local workstation, run the following command:
gcloud compute firewall-rules list
If the firewall rule is missing, add it back:
gcloud compute firewall-rules create default-allow-ssh --allow tcp:22
To view all data associated with the
default-allow-ssh firewall rule in your
project, use the
gcloud compute firewall-rules describe command:
gcloud compute firewall-rules describe default-allow-ssh --project
Test the network connection
To determine whether the network connection is working, use the nmap
tool to connect to your instance on port 22. If you connect and see
22/tcp open ssh, your network connection is working, and you can rule
out firewall problems.
gcloudtool to obtain the external
natIPfor your instance:
gcloud compute instances describe $PROB_INSTANCE \ --format='get(networkInterfaces.accessConfigs.natIP)' \ 198.51.100.1
Test the network connection to your instance.
nmapcommand to test the network connection to your instance, replacing
external-ipwith the external IP of the instance:
For example, if the instance has the external IP
198.51.100.1, run the following command:
Starting Nmap 7.70 ( https://nmap.org ) at 2019-03-18 16:04 Greenwich Standard Time Nmap scan report for 126.96.36.199.bc.googleusercontent.com (198.51.100.1) Host is up (0.0061s latency). Not shown: 998 filtered ports PORT STATE SERVICE 22/tcp open ssh Nmap done: 1 IP address (1 host up) scanned in 6.22 seconds
Connect as a different user
The issue that prevents you from logging in might be limited to your user
account. For example, the permissions on the
on the instance might not be set correctly for the user.
Try logging in as a different user with the
gcloud tool by
another-username with the SSH request.
gcloud tool updates the project's metadata to add the
new user and allow SSH access.
gcloud compute ssh another-username@$PROB_INSTANCE
Debug the issue in the serial console
We recommend that you review the logs from the serial console for connection errors. You can access the serial console from your local workstation by using a browser.
Enable read/write access to an instance's serial console, so you can log into the console and troubleshoot problems with the instance. This approach is useful when you cannot log in with SSH, or if the instance has no connection to the network. The serial console remains accessible in both of these situations.
To learn how to enable interactive access and connect to an instance's serial console, read Interacting with the serial console.
Inspect the VM instance without shutting it down
You might have an instance that you cannot connect to that continues to correctly serve production traffic. In this case, you might want to inspect the disk without interrupting the instance.
To inspect and troubleshoot the disk:
- Back up your boot disk by creating a snapshot of the disk.
- Create a regular persistent disk from that snapshot.
- Create a temporary instance.
- Attach and mount the regular persistent disk to your new temporary instance.
This procedure creates an isolated network that only allows SSH connections. This setup prevents any unintended consequences of the cloned instance interfering with your production services.
Create a new VPC network to host your cloned instance:
gcloud compute networks create debug-network
Add a firewall rule to allow SSH connections to the network:
gcloud compute firewall-rules create debug-network-allow-ssh \ --allow tcp:22
Create a snapshot of the boot disk.
gcloud compute disks snapshot $BOOT_DISK \ --snapshot-names debug-disk-snapshot
Create a new disk with the snapshot you just created:
gcloud compute disks create example-disk-debugging \ --source-snapshot debug-disk-snapshot
Create a new debugging instance without an external IP address:
gcloud compute instances create debugger \ --network debug-network \ --no-address
Attach the debugging disk to the instance:
gcloud compute instances attach-disk debugger \ --disk example-disk-debugging
Follow the instructions to connect to an instance without an external IP address.
After you have logged into the debugger instance, troubleshoot the instance. For example, you can look at the instance logs:
sudo su -
mount /dev/disk/by-id/scsi-0Google_PersistentDisk_example-disk-debugging /mnt/$PROB_INSTANCE
# Identify the issue preventing ssh from working ls
Use a startup script
If none of the preceding helped, you can create a startup script to collect information right after the instance starts. Follow the instructions for running a startup script.
Afterward, you also need to reset your instance before the metadata takes
effect by using
gcloud compute instances reset.
Alternatively, you can also recreate your instance by running a diagnostic startup script:
gcloud compute instances deletewith the
gcloud compute instances delete $PROB_INSTANCE \ --keep-disks boot
Add a new instance with the same disk and specify your startup script.
gcloud compute instances create new-instance \ --disk name=$BOOT_DISK,boot=yes \ --startup-script-url URL
As a starting point, you can use the compute-ssh-diagnostic script to collect diagnostics information for most common issues.
Use your disk on a new instance
If you still need to recover data from your persistent boot disk, you can detach the boot disk and then attach that disk as a secondary disk on a new instance.
gcloud compute instances delete $PROB_INSTANCE \ --keep-disks=boot
gcloud compute instances create new-instance \ --disk name=$BOOT_DISK,boot=yes,auto-delete=no
gcloud compute ssh new-instance