Ssh 255 error code

sftp error code 255 – How to make it work!

by Sijin George | Nov 16, 2019

Are you struggling with sftp error code 255?

SFTP is a secure method for file upload.

However, it often shows errors when the remote server is down/unavailable, the remote machine doesn’t have ssh access or has firewall restrictions.

At Bobcares, we often get requests from our customers to fix an error message sftp error code 255 as part of our Server Management Services.

Today, let’s get into the details on how our Support Engineers fix this error.

Why sftp error code 255?

Usually, the exit code 255 is a frequent error that happens due to the problem in SSH access.

The error appears like the following

The following reasons are the common cause of this error.

If the remote server to which we are trying to connect is unavailable or down, then the connection via sftp has not been established, and so we received this error.

In addition to this, we will get the same error if the remote server is not having the ssh access to the server or if there is any firewall restriction.

Now let’s detail the reason for this error and how our Support Engineers fix the problem.

The causes and fixes of sftp error code 255

At Bobcares, where we have more than a decade of expertise in managing servers, we see many customers facing problems with error sftp error code 255.

Now, let’s see the major reasons for this sftp related errors and how our Support Engineers fix them.

1. Missing RSA key

Recently, while connecting to the server via sftp one of our customers was getting the error sftp error code 255. Initially, his public key authentication was successful. But after a while, the connection got disconnected.

On checking, our Support Engineers found that the public key was working and could not trace anything wrong with it. However, we found that he had only created DSA keys, and RSA keys were missing.

Therefore, we created RSA keys and also inserted the public keys in his authorized keys file, then everything worked fine.

This resolved the error and the customer could regain sftp connection.

2. Firewall restrictions

Firewall restrictions can also be a reason for sftp failure. It will restrict unauthorized IP access or port access to the server for security purposes.

Sometimes, the error sftp error code 255 happens due to the sftp port restricted in the firewall. In such cases, our Support Engineers will first check for any firewall restrictions. Firewall restrictions can cause timeout errors while trying to connect to the server using sftp.

This has been caused due to some server-side settings or sftp port (default 22)blocks on the network.

So, our Support Engineers check the log files and confirm that it does not cause the sftp to exit connection.

For instance, we check the IPtables to see if there are any IP restrictions.

If so, we will remove the IP restrictions to fix this error.

3. Permission of sftp

Sometimes, if there was no sftp server on the remote end, customers will receive the same error. Here, our Support Engineers confirm the working of the sftp server.

Another important cause to receive this error is incorrect permission of /home/user and .ssh folder on the remote server.

Here, we check the permission of the user and .ssh folder and correct it as follows.

Generally, the /home/user folder should be with 755 permission and the .ssh folder is with 700 permission.

By ensuring this, we can avoid unwanted errors happens while connected to the remote server via sftp.

[Struggling with sftp connection errors? We are here to help you.]

Conclusion

In short, sftp error code 255 error has been received mainly due to the problems in the remote server such as missing RSA keys, firewall restrictions, and so on. Today we discussed the reasons causing sftp error code 255 and saw how our Support Engineers fix this error for our customers.

PREVENT YOUR SERVER FROM CRASHING!

Never again lose customers to poor server speed! Let us help you.

Our server experts will monitor & maintain your server 24/7 so that it remains lightning fast and secure.

Источник

Скрипт ssh возвращает ошибку 255

В моем коде у меня есть следующее для запуска удаленного скрипта.

По какой-то причине он держит меня в напряжении. Любые идеи?

Я могу подключиться к ящику по SSH (настройка беспарольных ключей)

задан 14 фев ’13, 23:02

По какой-то причине ваш удаленные script возвращает 255, а ssh просто доставляет вам свой результат. Как насчет того, чтобы показать нам сценарий? — Anton Kovalenko

Предупреждаю: не используйте ненужные правки, чтобы постоянно ставить свой вопрос в начало очереди. Если вы сделаете это снова, я закрою этот вопрос. — Brad Larson

Одна вещь, которую я часто забываю при перемещении клиента на другую машину, это то, что когда вы делаете это в первый раз, вас просят подтвердить отпечаток пальца, поэтому, если вы не делаете это в интерактивном режиме, это не удается, пока вам не удастся ответить на этот вопрос вручную для той же учетной записи. . — frankieandshadow

Я нашел свою аналогичную проблему, так что на случай, если это поможет кому-то еще . Я мог бы использовать ssh в командной строке, но не при запуске из скрипта. Проблема заключалась в том, что у меня была включена переадресация агента, когда я входил в систему. Из которого Я выполнял ssh, поэтому проблема с моим сертификатом (который заключался в том, что у меня не было прав доступа) не появлялась, потому что вместо этого использовался мой перенаправленный ключ. Мне пришлось отключить переадресацию агента, чтобы увидеть сообщение об ошибке, которое сценарий, предположительно, также получал, но не отображался в выходных данных. — frankieandshadow

Я получил ошибку 255 при переадресации порта на сервер с автосш. Каждый раз, когда мой Интернет отключался, сервер не замечал, что соединение прервано, и не освобождал порт, на который я перенаправлял. Это предотвратило новое соединение, инициированное автосш от привязки к порту, что приводит к сбою с ошибкой 255. Решение состояло в том, чтобы установить ClientAliveInterval в sshd_config файл на сервере. — SomeDude

8 ответы

Обычно это происходит, когда пульт не работает/недоступен; или на удаленной машине не установлен ssh; или брандмауэр не позволяет установить соединение с удаленным хостом.

ssh возвращает 255 при возникновении ошибки или 255 возвращается удаленным скриптом:

Обычно вы получаете сообщение об ошибке, похожее на:

Чек-лист:

Что произойдет, если вы запустите команду ssh прямо из командной строки?

Можете ли вы ping эта машина?

На пульте установлен ssh?

Если установлена, то запущена ли служба ssh?

Источник

SSH server won’t start, exit code 255

Bug Description

I keep trying to set up external SSH access using openssh server on my 18.04 system and it throws back this error

sudo service ssh status
● ssh.service — OpenBSD Secure Shell server
Loaded: loaded (/lib/systemd/ system/ ssh.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Sat 2018-07-07 09:33:19 CDT; 12min ago
Process: 3243 ExecStartPre= /usr/sbin/ sshd -t (code=exited, status=255)

Jul 07 09:33:19 warehouse systemd[1]: ssh.service: Service hold-off time over, scheduling restart.
Jul 07 09:33:19 warehouse systemd[1]: ssh.service: Scheduled restart job, restart counter is at 5.
Jul 07 09:33:19 warehouse systemd[1]: Stopped OpenBSD Secure Shell server.
Jul 07 09:33:19 warehouse systemd[1]: ssh.service: Start request repeated too quickly.
Jul 07 09:33:19 warehouse systemd[1]: ssh.service: Failed with result ‘exit-code’.
Jul 07 09:33:19 warehouse systemd[1]: Failed to start OpenBSD Secure Shell server.

I was in the process of uninstalling the openssh-server and ssh packages and was prompted to start a bug report. If it’s in error, just let me know. My ssh config file is all default except for passwordauthent ication = yes. I’ve toggled that to default as well, and still get the same error.

ProblemType: Package
DistroRelease: Ubuntu 18.04
Package: openssh-server 1:7.6p1-4
ProcVersionSign ature: Ubuntu 4.15.0- 23.25-generic 4.15.18
Uname: Linux 4.15.0-23-generic x86_64
NonfreeKernelMo dules: kpatch_ livepatch_ Ubuntu_ 4_15_0_ 23_25_generic_ 40
ApportVersion: 2.20.9-0ubuntu7.2
AptOrdering:
openssh- server: amd64: Install
ssh:amd64: Install
NULL: ConfigurePending
Architecture: amd64
Date: Sat Jul 7 09:48:11 2018
ErrorMessage: installed openssh-server package post-installation script subprocess returned error exit status 1
InstallationDate: Installed on 2018-07-07 (0 days ago)
InstallationMedia: Ubuntu 18.04 LTS «Bionic Beaver» — Release amd64 (20180426)
Python3Details: /usr/bin/python3.6, Python 3.6.5, python3-minimal, 3.6.5-3
PythonDetails: N/A
RelatedPackageV ersions:
dpkg 1.19.0.5ubuntu2
apt 1.6.2
SSHDConfig:
Error: command [‘/usr/sbin/sshd’, ‘-T’] failed with exit code 255: /etc/ssh/ sshd_config: line 1: Bad configuration option: 342200 213342 200213
/etc/ssh/ sshd_config: terminating, 1 bad configuration options
SourcePackage: openssh
Title: package openssh-server 1:7.6p1-4 failed to install/upgrade: installed openssh-server package post-installation script subprocess returned error exit status 1
UpgradeStatus: No upgrade log present (probably fresh install)

Источник

rsync error: unexplained error (code 255) at io.c(226) [sender=3.1.2] [closed]

Questions describing a problem that can’t be reproduced and seemingly went away on its own (or went away when a typo was fixed) are off-topic as they are unlikely to help future readers.

Closed 3 years ago .

Good day everyone. I’m trying to rsync to my Manjaro server over ssh. Nothing fancy, just a single PNG in order to verify that it works. I’m using a basic password authentication in order to verify that I can get it functioning before I start packing on extra security.

When I do that, about 10 seconds go by until I receive the following error.

I’m no stranger to ssh but this is something beyond my modest understanding of the deep inner workings. I googled the problem but I didn’t want to throw arbitrary solutions at my system without first understanding the problem. I’ll explain what I have done in order to gather more information. I have 3 systems.

1. Win10-PC with Cygwin (fully updated) (Atheros Wireless)
2. Arch-Laptop (fully updated) (Atheros Wireless)
3. Manjaro-Server (fully updated) (Wired)

First thing I checked was sshd. Enabled and restarted sshd on all 3 machines. It’s worth noting that my Manjaro is a brand spanking new install. Arch has been modified but the system is very minimal. Cygwin is also new but It’s been awhile since I reinstalled Windows and I have a few things running in the background. I also forwarded the ports and disabled the firewall on my router.

Ran the three commands.

All of these commands work. What that means is that: logging into the machine via ssh works, copying files to the server works and rsync works. The problem exists when I try to rsync via ssh. One of two possibilities exists. Either there is something wrong with the server, or I missed some fundamental step in configuring ssh on both client computers. It’s more likely the former. Like I said, I had prior experience setting up ssh and it wasn’t that hard the first few times. I started by checking the ssh and rsync versions I was running.

Win10-PC (sshd enabled and started)

Arch-Laptop (sshd enabled and started)

Manjaro-Server (sshd enabled and started)

You may have noticed the Cygwin version of openssl is not as high as the other two. I don’t think this could cause the problem since Arch also can not connect to the network. Like I said before, Either there is something wrong with the server, or I missed some fundamental step in configuring ssh on both client computers.

I also read this thread but I’m not sure if the chosen answer wants me to configure the ssh_config file on the host of the client. In either case, a simple png should not take this long to rsync so I doubt it has anything to do with the problem but I’ll leave it here in just in case

If you have an answer off the top of your head, awesome. If you don’t, then posting something that can help further isolate the problem would be equally appreciated. Thank you so much for your help.

Источник

Error creating machine: Error getting SSH command: exit status 255 #1559

The machine was created, but without docker.

The text was updated successfully, but these errors were encountered:

+1. This happens with me as well. Just gets stuck at Creating Digital Ocean droplet. for a long time even though the droplet is actually up and running.

docker-machine version 0.4.0 (9d0dc7a)

docker-machine version 0.4.1 (HEAD)

I’m using the generic driver. I can SSH to the remote server without password.

Having the same issues with the generic driver (none)

docker-machine version 0.4.1 (e2c88d6)

+1
docker-machine version 0.4.1 (e2c88d6)

I believe I had this error due to a pre-existing ‘default’ Virtualbox machine. I deleted it and also uninstalled/reinstalled and all is now clear for me on Win8 box.

The same issue happens on centos 7.3.

(test) DBG | SSH cmd err, output: exit status 255:
(test) DBG | Error getting ssh command ‘exit 0’ : ssh command error:
(test) DBG | command : exit 0
(test) DBG | err : exit status 255
docker-machine version 0.12.2, build 9371605
WTF?

Getting to WaitForSSH function.
(sandboxprovisiontest) Calling .GetSSHHostname
(sandboxprovisiontest) Calling .GetSSHPort
(sandboxprovisiontest) Calling .GetSSHKeyPath
(sandboxprovisiontest) Calling .GetSSHKeyPath
(sandboxprovisiontest) Calling .GetSSHUsername
Using SSH client type: external
Using SSH private key: /Users/xxxxxl/.docker/machine/machines/sandboxprovisiontest/id_rsa (-rw——-)
&<[-F /dev/null -o ConnectionAttempts=3 -o ConnectTimeout=10 -o ControlMaster=no -o ControlPath=none -o LogLevel=quiet -o PasswordAuthentication=no -o ServerAliveInterval=60 -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null root@142.93.64.40 -o IdentitiesOnly=yes -i /Users/vxxxxxl/.docker/machine/machines/sandboxprovisiontest/id_rsa -p 22] /usr/bin/ssh >
About to run SSH command:
exit 0
SSH cmd err, output: exit status 255:
Error getting ssh command ‘exit 0’ : ssh command error:
command : exit 0
err : exit status 255
output :
Getting to WaitForSSH function.

NO clue how to fix this.
docker version
Client: Docker Engine — Community
Version: 18.09.2
API version: 1.39
Go version: go1.10.8
Git commit: 6247962
Built: Sun Feb 10 04:12:39 2019
OS/Arch: darwin/amd64
Experimental: false

Server: Docker Engine — Community
Engine:
Version: 18.09.2
API version: 1.39 (minimum version 1.12)
Go version: go1.10.6
Git commit: 6247962
Built: Sun Feb 10 04:13:06 2019
OS/Arch: linux/amd64
Experimental: true

Same problem, no solution.

docker-machine version 0.16.0, build 702c267f

So I solved this, at least for my case. Here’s for posterity:

The important line in the output (run docker-machine -B . to get debug info) is the following:

It does some shell wizardry you can ignore, just remove the cruft from the start, and put the /usr/bin/ssh in the beginning and run. With the example above, that would be:

/usr/bin/ssh -F /dev/null -o ConnectionAttempts=3 -o ConnectTimeout=10 -o ControlMaster=no -o ControlPath=none -o LogLevel=quiet -o PasswordAuthentication=no -o ServerAliveInterval=60 -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null root@142.93.64.40 -o IdentitiesOnly=yes -i /Users/vxxxxxl/.docker/machine/machines/sandboxprovisiontest/id_rsa -p 22

After it fails, remove the -o LogLevel=quiet and it might tell you what’s wrong.

In my case–and this is unfortunately where our cases diverge– the reference to the identity/private key was actually missing, i. e. the -I /Users/vxxxxxl/.docker/machine/machines/sandboxprovisiontest/id_rsa . I edited /home//.docker/machine/machines//config.json and added the path under Driver -> SSHKeyPath.

In the examples here, the problem seems to be different. Check if the path is correct and also check permissions on the file. It should be 600.

Источник

Are you struggling with sftp error code 255?

SFTP is a secure method for file upload.

However, it often shows errors when the remote server is down/unavailable, the remote machine doesn’t have ssh access or has firewall restrictions.

At Bobcares, we often get requests from our customers to fix an error message sftp error code 255 as part of our Server Management Services.

Today, let’s get into the details on how our Support Engineers fix this error.

Why sftp error code 255?

Usually, the exit code 255 is a frequent error that happens due to the problem in SSH access.

The error appears like the following

The following reasons are the common cause of this error.

If the remote server to which we are trying to connect is unavailable or down, then the connection via sftp has not been established, and so we received this error.

In addition to this, we will get the same error if the remote server is not having the ssh access to the server or if there is any firewall restriction.

Now let’s detail the reason for this error and how our Support Engineers fix the problem.

The causes and fixes of sftp error code 255

At Bobcares, where we have more than a decade of expertise in managing servers, we see many customers facing problems with error sftp error code 255.

Now, let’s see the major reasons for this sftp related errors and how our Support Engineers fix them.

1. Missing RSA key

Recently, while connecting to the server via sftp one of our customers was getting the error sftp error code 255. Initially, his public key authentication was successful. But after a while, the connection got disconnected.

On checking, our Support Engineers found that the public key was working and could not trace anything wrong with it. However, we found that he had only created DSA keys, and RSA keys were missing.

Therefore, we created RSA keys and also inserted the public keys in his authorized keys file, then everything worked fine.

This resolved the error and the customer could regain sftp connection.

2. Firewall restrictions

Firewall restrictions can also be a reason for sftp failure. It will restrict unauthorized IP access or port access to the server for security purposes.

Sometimes, the error sftp error code 255 happens due to the sftp port restricted in the firewall. In such cases, our Support Engineers will first check for any firewall restrictions. Firewall restrictions can cause timeout errors while trying to connect to the server using sftp.

This has been caused due to some server-side settings or sftp port (default 22)blocks on the network.

So, our Support Engineers check the log files and confirm that it does not cause the sftp to exit connection.

For instance, we check the IPtables to see if there are any IP restrictions.

iptables -nL | grep xx.xx.xx.xx

If so, we will remove the IP restrictions to fix this error.

3. Permission of sftp

Sometimes, if there was no sftp server on the remote end, customers will receive the same error. Here, our Support Engineers confirm the working of the sftp server.

Another important cause to receive this error is incorrect permission of /home/user and .ssh folder on the remote server.

Here, we check the permission of the user and .ssh folder and correct it as follows.

chmod 755 /home/user
chmod 700 /home/user/.ssh

Generally, the /home/user folder should be with 755 permission and the .ssh folder is with 700 permission.

By ensuring this, we can avoid unwanted errors happens while connected to the remote server via sftp.

[Struggling with sftp connection errors? We are here to help you.]

Conclusion

In short, sftp error code 255 error has been received mainly due to the problems in the remote server such as missing RSA keys, firewall restrictions, and so on. Today we discussed the reasons causing sftp error code 255 and saw how our Support Engineers fix this error for our customers.

var google_conversion_label = «owonCMyG5nEQ0aD71QM»;

What were you trying to do?

Swap deployment: telepresence --swap-deployment portal-app --namespace dev-1 --env-json portal_env.json

What did you expect to happen?

swap the deployment with a proxy that will forward all network communications to/from the service that I will run locally

What happened instead?

Process exited and with the below error information

Automatically included information

Command line: ['/usr/local/bin/telepresence', '--swap-deployment', 'portal-app', '--namespace', 'dev-1', '--env-json', 'portal_env.json']
Version: 0.105
Python version: 3.8.1 (default, Jan 21 2020, 19:37:00) [Clang 11.0.0 (clang-1100.0.33.17)]
kubectl version: Client Version: v1.16.6-beta.0 // Server Version: v1.18.4
oc version: (error: [Errno 2] No such file or directory: 'oc')
OS: Darwin Martijn-MBP-2106.local 19.5.0 Darwin Kernel Version 19.5.0: Tue May 26 20:41:44 PDT 2020; root:xnu-6153.121.2~2/RELEASE_X86_64 x86_64

Background process (SSH port forward (exposed ports)) exited with return code 255. Command was:
  ssh -N -oServerAliveInterval=1 -oServerAliveCountMax=10 -F /dev/null -oStrictHostKeyChecking=no -oUserKnownHostsFile=/dev/null -q -p 50433 telepresence@127.0.0.1 -R '*:8080:127.0.0.1:8080'


Background process (SSH port forward (socks and proxy poll)) exited with return code 255. Command was:
  ssh -N -oServerAliveInterval=1 -oServerAliveCountMax=10 -F /dev/null -oStrictHostKeyChecking=no -oUserKnownHostsFile=/dev/null -q -p 50433 telepresence@127.0.0.1 -L127.0.0.1:50443:127.0.0.1:9050 -R9055:127.0.0.1:50444

Logs:

bytes
  13.5 TEL | [52] timed out after 1.00 secs.
  13.6 TEL | Wait for vpn-tcp connection: hellotelepresence-11
  13.6 TEL | [53] Capturing: python3 -c 'import socket; socket.gethostbyname("hellotelepresence-11")'
  13.6  30 | c : DNS request from ('2001:1c02:b22:ec00:5589:4b6d:c3db:cee3', 54902, 0, 0) to None: 43 bytes
  14.6  30 | c : DNS request from ('2001:1c02:b22:ec00:5589:4b6d:c3db:cee3', 54902, 0, 0) to None: 43 bytes
  16.0  30 | c : DNS request from ('2001:1c02:b22:ec00:5589:4b6d:c3db:cee3', 51068, 0, 0) to None: 46 bytes
  18.2 TEL | [26] SSH port forward (exposed ports): exit 255
  18.2 TEL | [27] SSH port forward (socks and proxy poll): exit 255
  18.6 TEL | [53] timed out after 5.01 secs.
  18.6 TEL | [54] Capturing: python3 -c 'import socket; socket.gethostbyname("hellotelepresence-11.a.sanity.check.telepresence.io")'
  18.6  30 | c : DNS request from ('2001:1c02:b22:ec00:5589:4b6d:c3db:cee3', 49464, 0, 0) to None: 69 bytes
  19.6 TEL | [54] timed out after 1.00 secs.

Linux

Windows

This document describes common errors that you may run into when connecting to
virtual machine (VM) instances using SSH, ways to resolve errors, and
methods for diagnosing failed SSH connections.

Use the SSH troubleshooting tool to help determine why an SSH connection failed.
The troubleshooting tool performs the following tests to check for the cause of
failed SSH connections:

• User permissions tests: Checks if you have the required IAM
  permissions to connect to the VM using SSH.
• Network connectivity tests: Checks if the VM is connected to the network.
• VM instance status tests: Checks the VM’s CPU status to see if the VM is
  running.
• VPC settings tests: Checks the default SSH port.

Run the troubleshooting tool

You can use the Google Cloud console or the Google Cloud CLI to check for
networking problems and user permission errors that might cause SSH
connections to fail.

gcloud compute ssh VM_NAME 
    --troubleshoot

Review the results

After running the troubleshooting tool, do the following:

1. Review the test results to understand why the VM’s SSH connection isn’t
   working.
2. Resolve SSH connections by performing the remediation steps provided by
   the tool.

3. Try reconnecting to the VM.

   If the connection isn’t successful, try manually troubleshooting by doing
   the following:

   • Debug issues using the serial console
   • Ensure the VM is booting normally

Common SSH errors

The following are examples of common errors you might encounter when you use SSH
to connect to Compute Engine VMs.

SSH-in-Browser errors

The following error might occur when you connect to your VM using the
SSH-in-browser from
the Google Cloud console:

Unauthorized
Error 401

This error occurs if your user is part of an organization that is
managed from within Google Workspace and there is an active
restriction in the Workspace policy that prevents users from
accessing SSH-in-browser and the serial console within Google Cloud.

To resolve this issue, have a Google Workspace admin do the following:

1. Confirm that Google Cloud is enabled for the organization.

   If Google Cloud is disabled, enable it and retry the connection.

2. Confirm that services that aren’t controlled individually are enabled.

   If these services are disabled, enable them and retry the connection.

If the problem persists after enabling Google Cloud settings in
Google Workspace, do the following:

1. Capture the network traffic in an HTTP Archive Format (HAR) file
   starting from when you start the SSH-in-Browser SSH connection.

2. Create a Cloud Customer Care case and attache the HAR file.

Linux errors

Permission denied (publickey)

The following error might occur when you connect to your VM:

USERNAME@VM_EXTERNAL_IP: Permission denied (publickey).

This error can occur for several reasons. The following are some of the most
common causes of this error:

• You used an SSH key stored in metadata to connect to a VM that has OS Login
  enabled. If OS Login is enabled on your project, your VM doesn’t accept
  SSH keys that are stored in metadata. If you aren’t sure if OS Login is
  enabled, see
  Checking if OS Login is configured.

  To resolve this issue, try one of the following:

  • Connect to your VM using the Google Cloud console or the Google Cloud CLI. For
    more information, see
    Connecting to VMs.
  • Add your SSH keys to OS Login. For more information, see
    Add keys to VMs that use OS Login.
  • Disable OS Login. For more information, see
    Disabling OS Login.

• You used an SSH key stored in an OS Login profile to connect to a VM that
  doesn’t have OS Login enabled. If you disable OS Login, your VM doesn’t
  accept SSH keys that were stored in your OS Login profile. If you aren’t sure
  if OS Login is enabled, see
  Checking if OS Login is configured.

  To resolve this issue, try one of the following:

  • Connect to your VM using the Google Cloud console or the Google Cloud CLI. For
    more information, see
    Connecting to VMs.
  • Enable OS Login. For more information, see
    Enabling OS Login.
  • Add your SSH keys to metadata. For more information, see
    Add SSH keys to VMs that use metadata-based SSH keys.

• The VM has OS Login enabled, but you don’t have sufficient IAM permissions
  to use OS Login. To connect to a VM that has OS Login enabled, you must have
  the permissions required for OS Login. If you aren’t sure if OS Login is
  enabled, see
  Checking if OS Login is configured.

  To resolve this issue,
  grant the required OS Login IAM roles.

• Your key expired and Compute Engine deleted your ~/.ssh/authorized_keys
  file. If you manually added SSH keys to your VM and then connected to your
  VM using the Google Cloud console, Compute Engine created a new key pair for
  your connection. After the new key pair expired, Compute Engine
  deleted your ~/.ssh/authorized_keys file in the VM, which included your
  manually added SSH key.

  To resolve this issue, try one of the following:

  • Connect to your VM using the Google Cloud console or the Google Cloud CLI. For
    more information, see
    Connecting to VMs.
  • Re-add your SSH key to metadata. For more information, see
    Add SSH keys to VMs that use metadata-based SSH keys.

• You connected using a third-party tool and your SSH command is
  misconfigured. If you connect using the ssh command but don’t specify
  a path to your private key or you specify an incorrect path to your private
  key, your VM refuses your connection.

  To resolve this issue, try one of the following:

  • Run the following command:

    ssh -i PATH_TO_PRIVATE_KEY USERNAME@EXTERNAL_IP
    

    Replace the following:

    • PATH_TO_PRIVATE_KEY: the
      path to your private SSH key file.
    • USERNAME: the username of the user connecting
      to the instance. If you manage your SSH keys in metadata, the username
      is what you specified when you
      created the SSH key.
      For OS Login accounts,
      the username is defined in your Google profile.
    • EXTERNAL_IP: The external IP address for your
      VM.
  • Connect to your VM using the Google Cloud console or the Google Cloud CLI. When
    you use these tools to connect, Compute Engine manages key creation for
    you. For more information, see
    Connecting to VMs.

• Your VM’s guest environment is not running. If this is the first time that
  you are connecting to your VM and the guest environment is not running, then
  the VM might refuse your SSH connection request.

  To resolve this issue, do the following:

  1. Restart the VM.
  2. In the Google Cloud console, inspect the system startup logs in the
     serial port output to determine if the guest environment is
     running. For more information, see Validating the guest environment.
  3. If the guest environment is not running, manually install the guest
     environment by cloning VM’s boot disk and using a startup script.

• The sshd daemon isn’t running or isn’t configured
  properly. The sshd daemon enables SSH connections. If it’s misconfigured
  or not running, you can’t connect to your VM.

  To resolve this issue, try the following:

  • Review the user guide for your operating system to ensure that your
    sshd_config
    is set up correctly.

  • If you previously modified the folder permissions on your VM, change them
    back to the defaults:

    • 700 on the .ssh directory
    • 644 on the public key, which is stored in the ~/.ssh/authorized_keys
      folder

    Connect to the VM’s serial console as the root user, and modify the folder
    permissions:

    chmod 700 /home/USERNAME/.ssh; chmod 644 /home/USERNAME/.ssh/authorized_keys

    Replace USERNAME with the username for which you want to
    modify folder permissions.

• The VM’s boot disk is full. When an SSH connection is established, the
  guest environment adds the session’s public SSH key to the
  ~/.ssh/authorized_keys file. If the disk is full, the connection fails.

  To resolve this issue, do one or more of the following:

  • Confirm the boot disk is full by
    debugging with the serial console to identify
    no space left errors.
  • Resize the
    disk.
  • If you know which files are using the disk space,
    create a startup script that deletes
    unnecessary files and frees space. After the VM starts and you connect
    to it, delete the startup-script metadata.

• The permissions or ownership on $HOME, $HOME/.ssh, or
  $HOME/.ssh/authorized_keys is wrong.

  • Ownership: The guest environment stores a user’s public SSH key
    in the $HOME/.ssh/authorized_keys file. The owner of the $HOME
    directory, the $HOME/.ssh directory, and the authorized_keys file must
    be the same as the user connecting to the VM.

  • Unix permissions: The guest environment requires the following
    Unix permissions:

    Directory/File	Required Unix permission
    The $HOME directory	0755 or 0700
    The $HOME/.ssh directory	0700
    The authorized_keys file	0600

Connection failed

The following errors might occur when you connect to your VM from the
Google Cloud console or the gcloud CLI:

• The Google Cloud console:

  Connection Failed
  
  We are unable to connect to the VM on port 22.
  

• The gcloud CLI:

  ERROR: (gcloud.compute.ssh) [/usr/bin/ssh] exited with return code [255].
  

These errors can occur for several reasons. The following are some of the most
common causes of the errors:

• The VM is booting up and sshd is not running yet. You can’t
  connect to a VM before it is running.

  To resolve this issue, wait until the VM has finished booting and try to
  connect again.

• sshd is running on a custom port. If you configured sshd to run on a
  port other than port 22, you won’t be able to connect to your VM.

  To resolve this issue, create a custom firewall rule allowing tcp traffic on
  the port that your sshd is running on using the following command:

  gcloud compute firewall-rules create FIREWALL_NAME 
    --allow tcp:PORT_NUMBER
  

  For more information about creating custom firewall rules, see
  Creating firewall rules.

• The SSH firewall rule is missing or doesn’t allow traffic from
  IAP or the public internet. SSH connections are refused if
  firewall rules do not allow connections from IAP or TCP ingress
  traffic for IP range 0.0.0.0/0.

  To resolve this issue, do one of the following:

  • If you use Identity-Aware Proxy (IAP) for TCP forwarding, update your custom
    firewall rule to accept traffic from IAP, then check your IAM
    permissions.

    1. Update your custom firewall rule to allow traffic from 35.235.240.0/20,
       the IP address range that IAP uses for TCP forwarding. For
       more information, see
       Create a firewall rule.
    2. Grant permissions to use IAP TCP forwarding,
       if you haven’t already done so.

  • If you don’t use IAP update your custom firewall rule to
    allow ingress SSH traffic.

    1. Update your custom firewall rule to
       Allow ingress ssh connections to VMs.

• The SSH connection failed after you upgraded the VM’s kernel. A VM might
  experience a kernel panic after a kernel update, causing the VM to become
  inaccessible.

  To resolve this issue, do the following:

  1. Mount the disk to another
     VM.
  2. Update the grub.cfg file
     to use the previous version of the kernel.
  3. Attach the disk to the
     unresponsive VM.
  4. Verify that the status of the VM is RUNNING by using the
     gcloud compute instances describe command.
  5. Reinstall the kernel.
  6. Restart the VM.

  Alternatively, if you created a snapshot of the boot disk before
  upgrading the VM, use the snapshot to create a VM.

• The sshd daemon isn’t running or isn’t configured
  properly. The sshd daemon enables SSH connections. If it’s misconfigured
  or not running, you can’t connect to your VM.

  To resolve this issue, try the following:

  • Review the user guide for your operating system to ensure that your
    sshd_config
    is set up correctly.

  • If you previously modified the folder permissions on your VM, change them
    back to the defaults:

    • 700 on the .ssh directory
    • 644 on the public key, which is stored in the ~/.ssh/authorized_keys
      folder

    Connect to the VM’s serial console as the root user, and modify the folder
    permissions:

    chmod 700 /home/USERNAME/.ssh; chmod 644 /home/USERNAME/.ssh/authorized_keys

    Replace USERNAME with the username for which you want to
    modify folder permissions.

• The VM isn’t booting and you can’t connect using SSH or the serial
  console. If the VM is inaccessible, then your OS might be corrupted. If the
  boot disk doesn’t boot, you can diagnose the
  issue.
  If you want to recover the corrupted VM and retrieve data, see Recovering a
  corrupted VM or a full boot disk.

• The VM is booting in maintenance mode. When booting in maintenance mode,
  the VM doesn’t accept SSH connections, but you can connect to the VM’s serial
  console and log in as the root user.

  To resolve this issue, do the following:

  1. If you haven’t set a root password for the VM, use a
     metadata startup script to run
     the following command during boot:

     echo "NEW_PASSWORD" | chpasswd

     Replace NEW_PASSWORD with a password of your choice.

  2. Restart the VM.

  3. Connect to the VM’s serial console
     and log in as the root user.

Failed to connect to backend

The following errors might occur when you connect to your VM from the
Google Cloud console or the gcloud CLI:

• The Google Cloud console:

  -- Connection via Cloud Identity-Aware Proxy Failed
  
  -- Code: 4003
  
  -- Reason: failed to connect to backend
  

• The gcloud CLI:

  ERROR: (gcloud.compute.start-iap-tunnel) Error while connecting [4003: u'failed to connect to backend'].
  

These errors occur when you try to use SSH to connect to a VM that doesn’t have
a public IP address and for which you haven’t configured Identity-Aware Proxy on port
22.

To resolve this issue
Create a firewall rule on
port 22 that allows ingress traffic from Identity-Aware Proxy.

Host key does not match

The following error might occur when you connect to your VM:

Host key for server IP_ADDRESS does not match

This error occurs when the host key in the ~/.ssh/known_hosts file
doesn’t match the VM’s host key.

To resolve this issue, delete the host key from the ~/.ssh/known_hosts
file, then retry the connection.

Metadata value is too large

The following error might occur when you try to add a new SSH key to metadata:

ERROR:"Value for field 'metadata.items[X].value' is too large: maximum size 262144 character(s); actual size NUMBER_OF_CHARACTERS."

Metadata values have a
maximum limit of 256 KB.
To mitigate this limitation, do one of the following:

• Delete expired or duplicated SSH keys from project or instance metadata. For more
  information, see Update metadata on a running VM.
• Use OS Login.

Windows errors

Permission denied, please try again

The following error might occur when you connect to your VM:

USERNAME@compute.INSTANCE_ID's password:
Permission denied, please try again.

This error indicates the user trying to connect to the VM doesn’t exist on the
VM. The following are some of the most common causes of this error:

• Your version of gcloud CLI is out of date

  If gcloud CLI is out of date, you may be attempting to connect
  using a username that is not configured. To resolve this issue,
  update the gcloud CLI.

• You tried to connect to a Windows VM that doesn’t have SSH enabled.

  To resolve this error, set the enable-windows-ssh key to TRUE in project
  or instance metadata. For more information about setting medata, see
  Set custom metadata.

Permission denied (publickey,keyboard-interactive)

The following error might occur when you connect to a VM that doesn’t have SSH
enabled:

Permission denied (publickey,keyboard-interactive).

To resolve this error, set the enable-windows-ssh key to TRUE in project
or instance metadata. For more information about setting medata, see
Set custom metadata.

Could not SSH into the instance

The following error might occur when you connect to your VM from the
gcloud CLI:

ERROR: (gcloud.compute.ssh) Could not SSH into the instance.
It is possible that your SSH key has not propagated to the instance yet.
Try running this command again.  If you still cannot connect, verify that the firewall and instance are set to accept ssh traffic.

This error can occur for several reasons. The following are some of the most
common causes of the errors:

• You tried to connect to a Windows VM that doesn’t have SSH installed.

  To resolve this issue, follow the instructions to
  Enable SSH for Windows on a running VM.

• The sshd daemon isn’t running or isn’t configured properly. The sshd
  daemon enables SSH connections. If it’s misconfigured or not running, you
  can’t connect to a VM.

  To resolve this issue, review
  OpenSSH Server configuration for Windows Server and Windows
  to ensure that sshd is set up correctly.

Connection timed out

Timed out SSH connections might be caused by one of the following:

• The VM hasn’t finished booting. Allow a short time for the VM to boot.

  To resolve this issue, wait until the VM has finished booting and try to
  connect again.

• The SSH package isn’t installed. Windows VMs require you to install the
  google-compute-engine-ssh package before you can connect using SSH.

  To resolve this issue, install the SSH package.

Diagnose failed SSH connections

The following sections describe steps you can take to diagnose the cause of
failed SSH connections and the steps you can take to fix your connections.

Before you diagnose failed SSH connections, complete the following steps:

• Install or update to the latest version of the
  Google Cloud CLI.
• Run connectivity tests.
• If you are using a custom Linux image that isn’t running the guest environment,
  Install the Linux guest environment.
• If you use OS Login, view
  Troubleshooting OS Login.

Diagnosis methods for Linux and Windows VMs

Test connectivity

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
the 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=project-id

For more information about firewall rules, see
Firewall rules in Google Cloud.

Test the network connection

To determine whether the network connection is working, test the TCP handshake:

1. Obtain the external natIP for your VM:

   gcloud compute instances describe VM_NAME 
       --format='get(networkInterfaces[0].accessConfigs[0].natIP)'
   

   Replace VM_NAME with the name of the VM you can’t
   connect to.

2. Test the network connection to your VM from your workstation:

   Linux, Windows 2019/2022, and macOS

   curl -vso /dev/null --connect-timeout 5 EXTERNAL_IP:PORT_NUMBER
   

   Replace the following:

   • EXTERNAL_IP: the external IP address you
     obtained in the previous step
   • PORT_NUMBER: the port number

   If the TCP handshake is successful, the output is similar to the following:

   Expire in 0 ms for 6 (transfer 0x558b3289ffb0)
   Expire in 5000 ms for 2 (transfer 0x558b3289ffb0)
   Trying 192.168.0.4...
   TCP_NODELAY set
   Expire in 200 ms for 4 (transfer 0x558b3289ffb0)
   Connected to 192.168.0.4 (192.168.0.4) port 443 (#0)
   > GET / HTTP/1.1
   > Host: 192.168.0.4:443
   > User-Agent: curl/7.64.0
   > Accept: */*
   >
   Empty reply from server
   Connection #0 to host 192.168.0.4 left intact
   

   The Connected to line indicates a successful TCP handshake.

   Windows 2012 and 2016

   PS C:> New-Object System.Net.Sockets.TcpClient('EXTERNAL_IP',PORT_NUMBER)
   

   Replace the following:

   • EXTERNAL_IP: the external IP you obtained in
     the previous step
   • PORT_NUMBER: the port number

   If the TCP handshake is successful, the output is similar to the following:

   Available           : 0
   Client              : System.Net.Sockets.Socket
   Connected           : True
   ExclusiveAddressUse : False
   ReceiveBufferSize   : 131072
   SendBufferSize      : 131072
   ReceiveTimeout      : 0
   SendTimeout         : 0
   LingerState         : System.Net.Sockets.LingerOption
   NoDelay             : False
   

   The Connected: True line indicates a successful TCP handshake.

If the TCP handshake completes successfully, a software firewall rule is
not blocking the connection, the OS is correctly forwarding packets, and a
server is listening on the destination port. If the TCP handshake completes
successfully but the VM doesn’t accept SSH connections, the issue might be
with that the sshd daemon is misconfigured or not running properly. Review
the user guide for your operating system to ensure that your sshd_config
is set up correctly.

To run connectivity tests for analyzing the VPC network path configuration
between two VMs and check whether the programmed configuration should allow the
traffic, see Check for misconfigured firewall rules in Google Cloud.

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 ~/.ssh/authorized_keys file
on the instance might not be set correctly for the user.

Try logging in as a different user with the gcloud CLI by
specifying ANOTHER_USERNAME with the SSH request.
The gcloud CLI updates the project’s metadata to add the
new user and allow SSH access.

gcloud compute ssh ANOTHER_USERNAME@VM_NAME

Replace the following:

• ANOTHER_USERNAME is a username other than your own
  username
• VM_NAME is the name of the VM you want to connect to

Debug issues using the serial console

We recommend that you review the logs from the serial console for
connection errors. You can access the serial console as the root user from your
local workstation by using a browser. 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 log into the VM’s serial console and troubleshoot problems with the VM,
follow these steps::

1. Enable interactive access to the VM’s serial console.

2. For Linux VMs, modify the root password, add the following startup script to your VM:

   usermod -p $(echo "PASSWORD" | openssl passwd -1 -stdin) root

   Replace PASSWORD with a password of your choice.

3. Use the serial console to connect to your VM.

4. For Linux VMs, after you’re done debugging all the errors, disable the root account login:

   sudo passwd -l root

Diagnosis methods for Linux VMs

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:

1. Back up your boot disk by creating a snapshot of the disk.
2. Create a regular persistent disk from that snapshot.
3. Create a temporary instance.
4. 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.

1. Create a new VPC network to host your cloned instance:

   gcloud compute networks create debug-network
   

   Replace NETWORK_NAME with the name you want to call
   your new network.

2. Add a firewall rule to allow SSH connections to the network:

   gcloud compute firewall-rules create debug-network-allow-ssh 
      --network debug-network 
      --allow tcp:22
   

3. Create a snapshot of the boot disk.

   gcloud compute disks snapshot BOOT_DISK_NAME 
      --snapshot-names debug-disk-snapshot
   

   Replace BOOT_DISK_NAME with the name of the boot
   disk.

4. Create a new disk with the snapshot you just created:

   gcloud compute disks create example-disk-debugging 
      --source-snapshot debug-disk-snapshot
   

5. Create a new debugging instance without an external IP address:

   gcloud compute instances create debugger 
      --network debug-network 
      --no-address
   

6. Attach the debugging disk to the instance:

   gcloud compute instances attach-disk debugger 
      --disk example-disk-debugging
   

7. Follow the instructions to
   Connect to a VM using a bastion host.

8. After you have logged into the debugger instance, troubleshoot the instance.
   For example, you can look at the instance logs:

   sudo su -
   

   mkdir /mnt/VM_NAME
   

   mount /dev/disk/by-id/scsi-0Google_PersistentDisk_example-disk-debugging /mnt/VM_NAME
   

   cd /mnt/VM_NAME/var/log
   

   # Identify the issue preventing ssh from working
   ls
   

   Replace VM_NAME with the name of the VM you can’t
   connect to.

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:

1. Run gcloud compute instances delete with the --keep-disks flag.

   gcloud compute instances delete VM_NAME 
      --keep-disks boot
   

   Replace VM_NAME with the name of the VM you can’t
   connect to.

2. Add a new instance with the same disk and specify your startup script.

   gcloud compute instances create NEW_VM_NAME 
      --disk name=BOOT_DISK_NAME,boot=yes 
      --metadata startup-script-url URL
   

   Replace the following:

   • NEW_VM_NAME is the name of the new VM you’re
     creating
   • BOOT_DISK_NAME is the name of the boot disk from
     the VM you can’t connect to
   • URL is the Cloud Storage URL to the
     script, in either
     gs://BUCKET/FILE or
     https://storage.googleapis.com/BUCKET/FILE
     format.

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.

1. Delete the VM you can’t connect to and keep its boot disk:

   gcloud compute instances delete VM_NAME 
      --keep-disks=boot 

   Replace VM_NAME with the name of the VM you can’t
   connect to.

2. Create a new VM with your old VM’s boot disk.
   Specify the name of the boot disk of the VM you just deleted.

3. Connect to your new VM using SSH:

   gcloud compute ssh NEW_VM_NAME
   

   Replace NEW_VM_NAME with the name of your new VM.

Check whether or not the VM boot disk is full

Your VM might become inaccessible if its boot disk is full. This scenario can be
difficult to troubleshoot as it’s not always obvious when the VM connectivity
issue is due to a full boot disk. For more information about this scenario,
see Troubleshooting a VM that is inaccessible due to a full boot disk.

Diagnosis methods for Windows VMs

Reset SSH metadata

If you can’t connect to a Windows VM using SSH, try unsetting the
enable-windows-ssh metadata key and re-enabling SSH for Windows.

1. Set the enable-windows-ssh metadata key to FALSE. For information about
   how to set metadata, see
   Set custom metadata.

   Wait a few seconds for the change to take place.

2. Re-enable SSH for Windows

3. Reconnect to the VM.

Connect to the VM using RDP

If you can’t diagnose and resolve the cause of failed SSH connections to your
Windows VM, connect using RDP.

After you establish a connection to the VM, review the
OpenSSH logs.

What’s Next?

• Learn how SSH connections to Linux VMs work on
  Compute Engine.