SSH 오류 문제 해결

Linux Windows

이 문서에서는 SSH를 사용하여 가상 머신(VM) 인스턴스에 연결할 때 발생할 수 있는 일반적인 오류와 그러한 오류를 해결하는 방법, 실패한 SSH 연결을 진단하는 방법을 설명합니다.

SSH 문제 해결 도구

SSH 문제 해결 도구를 사용하여 SSH 연결이 실패한 이유를 확인합니다. 문제 해결 도구는 다음 테스트를 수행하여 SSH 연결이 실패한 원인을 확인합니다.

사용자 권한 테스트: SSH를 사용하여 VM에 연결하는 데 필요한 IAM 권한이 있는지 확인합니다.
네트워크 연결 테스트: VM이 네트워크에 연결되어 있는지 확인합니다.
VM 인스턴스 상태 테스트: VM의 CPU 상태를 확인하여 VM이 실행 중인지 확인합니다.
VPC 설정 테스트: 기본 SSH 포트를 확인합니다.

문제 해결 도구 실행

Google Cloud 콘솔 또는 Google Cloud CLI를 사용하여 SSH 연결이 실패할 수 있는 네트워킹 문제 및 사용자 권한 오류를 확인할 수 있습니다.

이 태스크에 필요한 권한

이 태스크를 수행하려면 다음과 같은 권한이 있어야 합니다.

VM에 대한 networkmanagement.connectivitytests.create 권한
VM에 대한 networkmanagement.connectivitytests.delete 권한
VM에 대한 networkmanagement.connectivitytests.get 권한

이러한 권한이 없으면 문제 해결 도구는 네트워크 연결 테스트를 건너뜁니다.

콘솔

SSH 연결이 실패하면 연결을 다시 시도하거나 브라우저에서 SSH를 통해 연결 문제 해결 도구를 사용하여 연결 문제를 해결할 수 있습니다.

문제 해결 도구를 실행하려면 문제 해결을 클릭합니다.

SSH 문제 해결 도구를 실행합니다.

gcloud

gcloud compute ssh 명령어를 사용하여 문제 해결 도구를 실행합니다.

gcloud compute ssh VM_NAME \
    --troubleshoot

VM_NAME을 연결할 수 없는 VM의 이름으로 바꿉니다.

도구에서 문제 해결 테스트를 수행하기 위한 권한을 제공하라는 메시지가 표시됩니다.

결과 검토

문제 해결 도구를 실행한 후 다음을 수행하세요.

테스트 결과를 검토하여 VM에 SSH 연결이 작동하지 않는 이유를 확인합니다.
도구에서 제공하는 해결 단계를 수행하여 SSH 연결을 해결합니다.
VM에 다시 연결해 봅니다.

연결에 실패하면 다음을 수행하여 수동으로 문제 해결을 시도해 보세요.
- 직렬 콘솔을 사용한 문제 디버그
- VM이 정상적으로 부팅되는지 확인

일반적인 SSH 오류

다음은 SSH를 사용하여 Compute Engine VM에 연결할 때 발생할 수 있는 일반적인 오류 예시입니다.

브라우저에서 SSH를 통해 연결 오류

승인되지 않은 오류 401

Google Cloud 콘솔에서 브라우저에서 SSH를 통해 연결을 사용하여 VM에 연결할 때 다음 오류가 발생할 수 있습니다.

Unauthorized
Error 401

이 오류는 사용자가 Google Workspace 내에서 관리되는 조직에 속해 있으며 사용자가 브라우저에서 SSH를 통해 연결 및 Google Cloud 내 직렬 콘솔에 액세스할 수 없도록 하는 활성 제한이 Workspace 정책에 있는 경우 발생합니다.

이 문제를 해결하려면 Google Workspace 관리자가 다음을 수행하도록 합니다.

조직에 Google Cloud가 사용 설정되어 있는지 확인합니다.

Google Cloud가 사용 중지된 경우 사용 설정하고 연결을 다시 시도합니다.
개별 설정이 없는 서비스가 사용 설정되어 있는지 확인합니다.

이러한 서비스가 사용 중지된 경우 사용 설정하고 연결을 다시 시도합니다.

Google Workspace에서 Google Cloud 설정을 사용 설정한 후에도 문제가 지속되면 다음을 수행하세요.

브라우저에서 SSH를 통해 연결을 시작할 때부터 네트워크 트래픽을 HTTP 보관 형식(HAR) 파일로 캡처합니다.
Cloud Customer Care 케이스를 만들고 HAR 파일을 첨부합니다.

연결할 수 없음. 다시 시도하는 중...

SSH 세션을 시작할 때 다음 오류가 발생할 수 있습니다.

Could not connect, retrying ...

연결할 수 없음. 다시 시도하는 중...

이 문제를 해결하려면 다음 단계를 따르세요.

VM 부팅이 완료되면 연결을 다시 시도합니다. 연결에 실패할 경우 다음 명령어를 실행하여 VM이 비상 모드에서 부팅되지 않았는지 확인합니다.
```
gcloud compute instances get-serial-port-output VM_NAME \
| grep "emergency mode"
```
VM이 비상 모드에서 부팅되는 경우 VM 시작 프로세스의 문제를 해결하여 부팅 프로세스가 어디에서 실패하는지 확인합니다.
직렬 콘솔에서 다음 명령어를 실행하여 google-guest-agent.service 서비스가 실행 중인지 확인합니다.
```
systemctl status google-guest-agent.service
```
서비스가 사용 중지되었으면 다음 명령어를 실행하여 서비스를 사용 설정하고 시작합니다.
```
systemctl enable google-guest-agent.service
systemctl start google-guest-agent.service
```
Linux Google 에이전트 스크립트가 설치되었고 실행되는지 확인합니다. 자세한 내용은 Google 에이전트 상태 확인을 참조하세요. Linux Google 에이전트가 설치되어 있지 않으면 다시 설치합니다.
VM에 연결하는 데 필요한 역할이 있는지 확인합니다. VM이 OS 로그인을 사용하는 경우 OS 로그인 IAM 역할 할당을 참조하세요. VM에 OS 로그인을 사용하지 않는 경우 Compute 인스턴스 관리자 역할 또는 서비스 계정 사용자 역할(VM이 서비스 계정으로 실행되도록 설정된 경우)이 필요합니다. 역할은 인스턴스 또는 프로젝트 SSH 키 메타데이터를 업데이트하는 데 필요합니다.
다음 명령어를 실행하여 SSH 액세스를 허용하는 방화벽 규칙이 있는지 확인합니다.
```
gcloud compute firewall-rules list | grep "tcp:22"
```
인터넷 또는 배스천 호스트의 기본 경로가 있는지 확인합니다. 자세한 내용은 경로 확인을 참조하세요.
루트 볼륨의 디스크 공간이 부족한지 확인합니다. 자세한 내용은 전체 디스크 및 디스크 크기 조절 문제 해결을 참조하세요.
다음 명령어를 실행하여 VM의 메모리가 부족하지 않은지 확인합니다.
```
gcloud compute instances get-serial-port-output instance-name \
| grep "Out of memory: Kill process" - e "Kill process" -e "Memory cgroup out of memory" -e "oom"
```
VM의 메모리가 부족한 경우 직렬 콘솔에 연결하여 문제를 해결하세요.

Linux 오류

권한 거부됨(공개 키)

VM에 연결할 때 다음 오류가 발생할 수 있습니다.

USERNAME@VM_EXTERNAL_IP: Permission denied (publickey).

이 오류는 여러 가지 이유로 발생할 수 있습니다. 이 오류의 가장 일반적인 원인은 다음과 같습니다.

OS 로그인이 사용 설정된 VM에 연결하기 위해 메타데이터에 저장된 SSH 키를 사용했습니다. 프로젝트에서 OS 로그인이 사용 설정되었으면 메타데이터에 저장된 SSH 키가 VM에서 허용되지 않습니다. OS 로그인이 사용 설정되어 있는지 확실하지 않은 경우 OS 로그인이 구성되었는지 확인을 참조하세요.

이 문제를 해결하려면 다음 중 하나를 시도해 보세요.
- Google Cloud 콘솔 또는 Google Cloud CLI를 사용하여 VM에 연결합니다. 자세한 내용은 VM에 연결을 참조하세요.
- SSH 키를 OS 로그인에 추가합니다. 자세한 내용은 OS 로그인을 사용하는 VM에 키 추가를 참조하세요.
- OS 로그인을 사용 중지합니다. 자세한 내용은 OS 로그인 사용 중지를 참조하세요.
OS 로그인이 사용 설정되지 않은 VM에 연결하기 위해 OS 로그인 프로필에 저장된 SSH 키를 사용했습니다. OS 로그인을 사용 중지하면 OS 로그인 프로필에 저장된 SSH 키가 VM에서 허용되지 않습니다. OS 로그인이 사용 설정되어 있는지 확실하지 않은 경우 OS 로그인이 구성되었는지 확인을 참조하세요.

이 문제를 해결하려면 다음 중 하나를 시도해 보세요.
- Google Cloud 콘솔 또는 Google Cloud CLI를 사용하여 VM에 연결합니다. 자세한 내용은 VM에 연결을 참조하세요.
- OS 로그인을 사용 설정합니다. 자세한 내용은 OS 로그인 사용 설정을 참조하세요.
- 메타데이터에 SSH 키를 추가합니다. 자세한 내용은 메타데이터 기반 SSH 키를 사용하는 VM에 SSH 키 추가를 참조하세요.
VM에 OS 로그인이 사용 설정되었지만 OS 로그인을 사용할 수 있는 IAM 권한이 없습니다. OS 로그인이 사용 설정된 VM에 연결하려면 OS 로그인에 필요한 권한이 있어야 합니다. OS 로그인이 사용 설정되어 있는지 확실하지 않은 경우 OS 로그인이 구성되었는지 확인을 참조하세요.

이 문제를 해결하려면 필요한 OS 로그인 IAM 역할을 부여합니다.
키가 만료되어 Compute Engine에서 ~/.ssh/authorized_keys 파일이 삭제되었습니다. VM에 SSH 키를 수동으로 추가하고 Google Cloud 콘솔을 사용하여 VM에 연결한 경우, Compute Engine에서 해당 연결에 대해 새 키 쌍이 생성되었습니다. 새 키 쌍이 만료된 다음 Compute Engine에서 수동으로 추가된 SSH 키를 포함하는 ~/.ssh/authorized_keys 파일이 VM에서 삭제되었습니다.

이 문제를 해결하려면 다음 중 하나를 시도해 보세요.
- Google Cloud 콘솔 또는 Google Cloud CLI를 사용하여 VM에 연결합니다. 자세한 내용은 VM에 연결을 참조하세요.
- SSH 키를 메타데이터에 다시 추가합니다. 자세한 내용은 메타데이터 기반 SSH 키를 사용하는 VM에 SSH 키 추가를 참조하세요.
연결에 타사 도구가 사용되었고 SSH 명령어가 잘못 구성되었습니다. ssh 명령어를 사용하여 연결할 때 비공개 키 경로를 지정하지 않거나 비공개 키에 잘못된 경로를 지정하면 VM에서 해당 연결이 거부됩니다.

이 문제를 해결하려면 다음 중 하나를 시도해 보세요.
- 다음 명령어를 실행합니다.
```
ssh -i PATH_TO_PRIVATE_KEY USERNAME@EXTERNAL_IP
```
  다음을 바꿉니다.
  - PATH_TO_PRIVATE_KEY: 비공개 SSH 키 파일 경로입니다.
  - USERNAME: 인스턴스에 연결하는 사용자의 사용자 이름입니다. 메타 데이터에서 SSH 키를 관리하는 경우, 사용자 이름은 SSH 키를 만들 때 지정한 비밀번호입니다. OS 로그인 계정의 경우 사용자 이름은 Google 프로필에 정의되어 있습니다.
  - EXTERNAL_IP: VM의 외부 IP 주소입니다.
- Google Cloud 콘솔 또는 Google Cloud CLI를 사용하여 VM에 연결합니다. 이러한 도구를 사용하여 연결할 때는 Compute Engine에서 키 생성이 자동으로 관리됩니다. 자세한 내용은 VM에 연결을 참조하세요.
VM의 게스트 환경이 실행 중이 아닙니다. VM에 처음 연결하고 게스트 환경이 실행되고 있지 않으면 VM에서 SSH 연결 요청을 거부할 수 있습니다.

이 문제를 해결하려면 다음 단계를 따르세요.
1. VM을 다시 시작합니다.
2. Google Cloud 콘솔에서 직렬 포트 출력의 시스템 시작 로그를 검사하여 게스트 환경이 실행 중인지 확인합니다. 자세한 내용은 게스트 환경 검증을 참조하세요.
3. 게스트 환경이 실행 중이 아닌 경우 수동으로 VM의 부팅 디스크를 클론하고 시작 스크립트를 사용하여 게스트 환경을 설치합니다.
OpenSSH 데몬(sshd)이 제대로 실행되지 않거나 구성되지 않았습니다. sshd는 SSH 프로토콜을 통해 시스템에 대한 보안 원격 액세스를 제공합니다. 구성이 잘못되었거나 실행되고 있지 않으면 SSH를 통해 VM에 연결할 수 없습니다.

참고: sshd 관련 문제를 해결하려면, 루트 사용자로 VM의 직렬 콘솔에 연결해야 합니다.

이 문제를 해결하려면 다음 중 하나 이상을 사용해 보세요.
- 사용 중인 운영체제의 사용자 가이드를 검토하여 sshd_config가 올바르게 설정되었는지 확인합니다.
- 다음에 필요한 소유권 및 권한 설정이 있는지 확인합니다.
  - $HOME 및 $HOME/.ssh 디렉터리
  - $HOME/.ssh/authorized_keys 파일
  소유권
  게스트 환경은 승인된 SSH 공개 키를 $HOME/.ssh/authorized_keys 파일에 저장합니다. $HOME 및 $HOME/.ssh 디렉터리와 $HOME/.ssh/authorized_keys 파일의 소유자는 VM에 연결하는 사용자와 동일해야 합니다.
  
  권한
  게스트 환경에는 다음 Linux 권한이 필요합니다.
  
  경로 권한
  
  /home 0755
  
  $HOME 0700 또는 0750 또는 0755 ^*
  
  $HOME/.ssh 0700
  
  $HOME/.ssh/authorized_keys 0600
  
  ^* 어느 옵션이 $HOME 디렉터리에 대한 올바른 기본 권한인지 확인하려면 특정 Linux 배포판의 공식 문서를 참조하세요.
  
  또는 동일한 이미지를 기반으로 새 VM을 만들고 $HOME의 기본 권한을 확인할 수 있습니다.
  
  권한 및 소유권을 변경하는 방법을 알아보려면 chmod 및 chown을 참조하세요.
- 다음 명령어를 실행하여 sshd를 다시 시작합니다.
```
systemctl restart sshd.service
```
  다음 명령어를 실행하여 상태에 오류가 있는지 확인합니다.
```
systemctl status sshd.service
```
  상태 출력에는 종료 코드, 실패 이유 등의 정보가 포함될 수 있습니다. 이러한 세부정보를 사용하여 추가 문제를 해결할 수 있습니다.
VM의 부팅 디스크가 가득 찼습니다. SSH 연결이 설정되면 게스트 환경에서 세션의 공개 SSH 키를 ~/.ssh/authorized_keys 파일에 추가합니다. 디스크가 가득 차면 연결이 실패합니다.

이 문제를 해결하려면 다음 중 하나 이상을 수행합니다.
- no space left errors를 식별하기 위해 직렬 콘솔로 디버깅하여 부팅 디스크가 가득 찼는지 확인합니다.
- 디스크 크기를 조절합니다.
- 어떤 파일이 디스크 공간을 사용하고 있는지 알고 있다면 필요 없는 파일을 삭제해 공간을 확보하는 시작 스크립트를 만듭니다. VM이 시작하고 VM에 연결한 후 startup-script 메타데이터를 삭제합니다.
$HOME, $HOME/.ssh 또는 $HOME/.ssh/authorized_keys에 대한 권한이나 소유권이 잘못되었습니다.

소유권
게스트 환경은 승인된 SSH 공개 키를 $HOME/.ssh/authorized_keys 파일에 저장합니다. $HOME 및 $HOME/.ssh 디렉터리와 $HOME/.ssh/authorized_keys 파일의 소유자는 VM에 연결하는 사용자와 동일해야 합니다.

권한
게스트 환경에는 다음 Linux 권한이 필요합니다.

경로 권한

/home 0755

$HOME 0700 또는 0750 또는 0755 ^*

$HOME/.ssh 0700

$HOME/.ssh/authorized_keys 0600

^* 어느 옵션이 $HOME 디렉터리에 대한 올바른 기본 권한인지 확인하려면 특정 Linux 배포판의 공식 문서를 참조하세요.

또는 동일한 이미지를 기반으로 새 VM을 만들고 $HOME의 기본 권한을 확인할 수 있습니다.

권한 및 소유권을 변경하는 방법을 알아보려면 chmod 및 chown을 참조하세요.

경로	권한
`/home`	`0755`
`$HOME`	`0700` 또는 `0750` 또는 `0755` ^*
`$HOME/.ssh`	`0700`
`$HOME/.ssh/authorized_keys`	`0600`

경로	권한
`/home`	`0755`
`$HOME`	`0700` 또는 `0750` 또는 `0755` ^*
`$HOME/.ssh`	`0700`
`$HOME/.ssh/authorized_keys`	`0600`

연결 실패

Google Cloud 콘솔, gcloud CLI, 배스천 호스트, 로컬 클라이언트에서 VM에 연결할 때 다음 오류가 발생할 수 있습니다.

Google Cloud 콘솔:

Connection Failed

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

gcloud CLI:

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

배스천 호스트 또는 로컬 클라이언트:

port 22: Connection timed out.

port 22: Connection refused

이 오류는 여러 가지 이유로 발생할 수 있습니다. 다음은 이 오류의 가장 일반적인 원인 중 일부입니다.

VM이 부팅 중이며 sshd이 아직 실행 중이 아닙니다. 실행되기 전에는 VM에 연결할 수 없습니다.

이 문제를 해결하려면 VM이 부팅을 끝낼 때까지 기다린 다음 다시 연결을 시도합니다.
sshd이 커스텀 포트에서 실행 중입니다. 포트 22가 아닌 포트에서 실행되도록 sshd를 구성한 경우 VM에 연결할 수 없습니다.

이 문제를 해결하려면 다음 명령어를 사용하여 sshd가 실행 중인 포트에서 tcp 트래픽을 허용하는 커스텀 방화벽 규칙을 만듭니다.
```
gcloud compute firewall-rules create FIREWALL_NAME \
  --allow tcp:PORT_NUMBER
```
커스텀 방화벽 규칙 만들기에 대한 자세한 내용은 방화벽 규칙 만들기를 참조하세요.
SSH 방화벽 규칙이 없거나 IAP 또는 공개 인터넷에서 들어오는 트래픽을 허용하지 않습니다. 방화벽 규칙에서 IP 범위 0.0.0.0/0의 IAP 또는 TCP 인그레스 트래픽에서 연결을 허용하지 않으면 SSH 연결이 거부됩니다.

이 문제를 해결하려면 다음 중 한 가지를 따르세요.
- TCP 전달에 IAP(Identity-Aware Proxy)를 사용하는 경우 IAP의 트래픽을 허용하도록 커스텀 방화벽 규칙을 업데이트한 다음 IAM 권한을 확인합니다.
  1. IAP에서 TCP 전달에 사용하는 IP 주소 범위인 35.235.240.0/20의 트래픽을 허용하도록 커스텀 방화벽 규칙을 업데이트합니다. 자세한 내용은 방화벽 규칙 만들기를 참조하세요.
  2. 아직 수행하지 않은 경우 IAP TCP 전달을 사용할 권한을 부여합니다.
- IAP를 사용하지 않는 경우 인그레스 SSH 트래픽을 허용하도록 커스텀 방화벽 규칙을 업데이트합니다.
  1. 커스텀 방화벽 규칙을 업데이트하여 VM에 대한 인그레스 SSH 연결을 허용합니다.
VM 커널을 업그레이드한 후 SSH 연결에 실패했습니다. 커널 업데이트 후 VM에 커널 패닉이 발생하여 VM에 액세스하지 못할 수 있습니다.

이 문제를 해결하려면 다음 단계를 따르세요.
1. 다른 VM에 디스크를 마운트합니다.
2. 커널의 이전 버전을 사용하도록 grub.cfg 파일을 업데이트합니다.
3. 응답하지 않는 VM에 디스크를 연결합니다.
4. gcloud compute instances describe 명령어를 사용하여 VM 상태가 RUNNING인지 확인합니다.
5. 커널을 다시 설치합니다.
6. VM을 다시 시작합니다.
또는 VM을 업그레이드하기 전 부팅 디스크의 스냅샷을 만든 경우 스냅샷을 사용하여 VM을 만듭니다.
OpenSSH 데몬(sshd)이 제대로 실행되지 않거나 구성되지 않았습니다. sshd는 SSH 프로토콜을 통해 시스템에 대한 보안 원격 액세스를 제공합니다. 구성이 잘못되었거나 실행되고 있지 않으면 SSH를 통해 VM에 연결할 수 없습니다.

참고: sshd 관련 문제를 해결하려면, 루트 사용자로 VM의 직렬 콘솔에 연결해야 합니다.

이 문제를 해결하려면 다음 중 하나 이상을 사용해 보세요.
- 사용 중인 운영체제의 사용자 가이드를 검토하여 sshd_config가 올바르게 설정되었는지 확인합니다.
- 다음에 필요한 소유권 및 권한 설정이 있는지 확인합니다.
  - $HOME 및 $HOME/.ssh 디렉터리
  - $HOME/.ssh/authorized_keys 파일
  소유권
  게스트 환경은 승인된 SSH 공개 키를 $HOME/.ssh/authorized_keys 파일에 저장합니다. $HOME 및 $HOME/.ssh 디렉터리와 $HOME/.ssh/authorized_keys 파일의 소유자는 VM에 연결하는 사용자와 동일해야 합니다.
  
  권한
  게스트 환경에는 다음 Linux 권한이 필요합니다.
  
  경로 권한
  
  /home 0755
  
  $HOME 0700 또는 0750 또는 0755 ^*
  
  $HOME/.ssh 0700
  
  $HOME/.ssh/authorized_keys 0600
  
  ^* 어느 옵션이 $HOME 디렉터리에 대한 올바른 기본 권한인지 확인하려면 특정 Linux 배포판의 공식 문서를 참조하세요.
  
  또는 동일한 이미지를 기반으로 새 VM을 만들고 $HOME의 기본 권한을 확인할 수 있습니다.
  
  권한 및 소유권을 변경하는 방법을 알아보려면 chmod 및 chown을 참조하세요.
- 다음 명령어를 실행하여 sshd를 다시 시작합니다.
```
systemctl restart sshd.service
```
  다음 명령어를 실행하여 상태에 오류가 있는지 확인합니다.
```
systemctl status sshd.service
```
  상태 출력에는 종료 코드, 실패 이유 등의 정보가 포함될 수 있습니다. 이러한 세부정보를 사용하여 추가 문제를 해결할 수 있습니다.
VM이 부팅되지 않고 SSH 또는 직렬 콘솔을 사용하여 연결할 수 없습니다. VM에 액세스할 수 없으면 OS가 손상되었을 수 있습니다. 부팅 디스크가 부팅되지 않으면 문제를 진단할 수 있습니다. 손상된 VM을 복구하고 데이터를 검색하려면 손상된 VM 또는 전체 부팅 디스크 복구를 참조하세요.
VM이 유지보수 모드로 부팅 중입니다. 유지보수 모드에서 부팅할 때 VM은 SSH 연결을 허용하지 않지만 VM의 직렬 콘솔에 연결하고 루트 사용자로 로그인할 수 있습니다.

이 문제를 해결하려면 다음 단계를 따르세요.
1. VM에 루트 비밀번호를 설정하지 않은 경우 메타데이터 시작 스크립트를 사용하여 부팅 중에 다음 명령어를 실행합니다.
```
echo "root:NEW_PASSWORD" | chpasswd
```
  NEW_PASSWORD를 원하는 비밀번호로 바꿉니다.
2. VM을 다시 시작합니다.
3. VM의 직렬 콘솔에 연결하고 루트 사용자로 로그인합니다.

경로	권한
`/home`	`0755`
`$HOME`	`0700` 또는 `0750` 또는 `0755` ^*
`$HOME/.ssh`	`0700`
`$HOME/.ssh/authorized_keys`	`0600`

예기치 않은 오류

Linux VM에 연결하려고 할 때 다음 오류가 발생할 수 있습니다.

Connection Failed
You cannot connect to the VM instance because of an unexpected error. Wait a few moments and then try again.

이 문제는 여러 가지 이유로 발생할 수 있습니다. 이 오류의 일반적인 원인은 다음과 같습니다.

OpenSSH 데몬(sshd)이 제대로 실행되지 않거나 구성되지 않았습니다. sshd는 SSH 프로토콜을 통해 시스템에 대한 보안 원격 액세스를 제공합니다. 구성이 잘못되었거나 실행되고 있지 않으면 SSH를 통해 VM에 연결할 수 없습니다.

참고: sshd 관련 문제를 해결하려면, 루트 사용자로 VM의 직렬 콘솔에 연결해야 합니다.

이 문제를 해결하려면 다음 중 하나 이상을 사용해 보세요.
- 사용 중인 운영체제의 사용자 가이드를 검토하여 sshd_config가 올바르게 설정되었는지 확인합니다.
- 다음에 필요한 소유권 및 권한 설정이 있는지 확인합니다.
  - $HOME 및 $HOME/.ssh 디렉터리
  - $HOME/.ssh/authorized_keys 파일
  소유권
  게스트 환경은 승인된 SSH 공개 키를 $HOME/.ssh/authorized_keys 파일에 저장합니다. $HOME 및 $HOME/.ssh 디렉터리와 $HOME/.ssh/authorized_keys 파일의 소유자는 VM에 연결하는 사용자와 동일해야 합니다.
  
  권한
  게스트 환경에는 다음 Linux 권한이 필요합니다.
  
  경로 권한
  
  /home 0755
  
  $HOME 0700 또는 0750 또는 0755 ^*
  
  $HOME/.ssh 0700
  
  $HOME/.ssh/authorized_keys 0600
  
  ^* 어느 옵션이 $HOME 디렉터리에 대한 올바른 기본 권한인지 확인하려면 특정 Linux 배포판의 공식 문서를 참조하세요.
  
  또는 동일한 이미지를 기반으로 새 VM을 만들고 $HOME의 기본 권한을 확인할 수 있습니다.
  
  권한 및 소유권을 변경하는 방법을 알아보려면 chmod 및 chown을 참조하세요.
- 다음 명령어를 실행하여 sshd를 다시 시작합니다.
```
systemctl restart sshd.service
```
  다음 명령어를 실행하여 상태에 오류가 있는지 확인합니다.
```
systemctl status sshd.service
```
  상태 출력에는 종료 코드, 실패 이유 등의 정보가 포함될 수 있습니다. 이러한 세부정보를 사용하여 추가 문제를 해결할 수 있습니다.
알 수 없는 SSH 데몬 문제 알 수 없는 SSH 데몬 문제를 진단하려면 직렬 콘솔 로그에서 오류를 확인합니다.

직렬 콘솔 로그의 출력에 따라 다음을 수행하여 VM을 복구하고 SSH 데몬 관련 문제를 해결합니다.
1. 다른 Linux VM에 디스크를 연결합니다.
2. 마운트된 디스크가 있는 VM에 연결합니다.
3. OS 내부의 디스크를 VM 내부의 MOUNT_DIR 디렉터리에 마운트합니다.
4. 문제/오류에 대해 SSH 관련 로그인, /var/log/secure 또는 /var/log/auth.log를 확인합니다. 해결할 수 있는 문제가 있으면 해결을 시도합니다. 그렇지 않으면 지원 케이스를 만들고 로그를 연결합니다.
5. umount 명령어를 사용하여 OS에서 디스크를 마운트 해제합니다.
```
cd ~/
umount /mnt
```
6. VM에서 디스크를 분리합니다.
7. 원래 VM에 디스크를 연결합니다.
8. VM을 시작합니다.

경로	권한
`/home`	`0755`
`$HOME`	`0700` 또는 `0750` 또는 `0755` ^*
`$HOME/.ssh`	`0700`
`$HOME/.ssh/authorized_keys`	`0600`

백엔드에 연결할 수 없음

Google Cloud Console 또는 gcloud CLI에서 VM에 연결할 때 다음 오류가 발생할 수 있습니다.

Google Cloud 콘솔:

-- Connection via Cloud Identity-Aware Proxy Failed

-- Code: 4003

-- Reason: failed to connect to backend

gcloud CLI:

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

이러한 오류는 공개 IP 주소가 없고 IAP(Identity-Aware Proxy)가 포트 22로 구성되지 않은 VM에 SSH를 사용하여 연결하려고 할 때 발생합니다.

이 문제를 해결하려면 포트 22로 IAP(Identity-Aware Proxy)의 인그레스 트래픽을 허용하는 방화벽 규칙을 만듭니다.

호스트 키가 일치하지 않음

VM에 연결할 때 다음 오류가 발생할 수 있습니다.

Host key for server IP_ADDRESS does not match

이 오류는 ~/.ssh/known_hosts 파일의 호스트 키가 VM의 호스트 키와 일치하지 않을 때 발생합니다.

이 문제를 해결하려면 ~/.ssh/known_hosts 파일에서 호스트 키를 삭제하고 연결을 재시도합니다.

메타데이터 값이 너무 큼

메타데이터에 새 SSH 키를 추가하려고 시도할 때 다음 오류가 발생할 수 있습니다.

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

메타데이터 값은 최대 한도가 256KB입니다. 이 제한을 완화하려면 다음 중 하나를 수행합니다.

프로젝트 또는 인스턴스 메타데이터에서 만료되었거나 중복된 SSH 키를 삭제합니다. 자세한 내용은 실행 중인 VM에서 메타데이터 업데이트를 참조하세요.
OS 로그인을 사용합니다.

Windows 오류

권한 거부됨. 다시 시도해 주세요

VM에 연결할 때 다음 오류가 발생할 수 있습니다.

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

이 오류는 VM에 연결하려고 하는 사용자가 VM에 존재하지 않음을 나타냅니다. 이 오류의 가장 일반적인 원인은 다음과 같습니다.

gcloud CLI 버전이 오래되었습니다.

gcloud CLI가 오래된 경우 구성되지 않은 사용자 이름을 사용하여 연결하려고 할 수 있습니다. 이 문제를 해결하려면 gcloud CLI를 업데이트합니다.
SSH가 사용 설정되지 않은 Windows VM에 연결하려고 했습니다.

이 오류를 해결하려면 프로젝트나 인스턴스 메타데이터에서 enable-windows-ssh 키를 TRUE로 설정합니다. medata 설정에 대한 자세한 내용은 커스텀 메타데이터 설정을 참조하세요.

권한 거부됨(공개 키, 키보드 대화형)

SSH가 사용 설정되지 않은 VM에 연결할 때 다음 오류가 발생할 수 있습니다.

Permission denied (publickey,keyboard-interactive).

이 오류를 해결하려면 프로젝트나 인스턴스 메타데이터에서 enable-windows-ssh 키를 TRUE로 설정합니다. medata 설정에 대한 자세한 내용은 커스텀 메타데이터 설정을 참조하세요.

인스턴스에 SSH를 통해 연결할 수 없음

gcloud CLI에서 VM에 연결할 때 다음 오류가 발생할 수 있습니다.

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.

이 오류는 여러 가지 이유로 발생할 수 있습니다. 다음은 이 오류의 가장 일반적인 원인 중 일부입니다.

SSH가 설치되지 않은 Windows VM에 연결하려고 했습니다.

이 문제를 해결하려면 안내에 따라 실행 중인 VM에서 Windows용 SSH를 사용 설정합니다.
OpenSSH 서버(sshd)가 실행 중이 아니거나 올바르게 구성되지 않았습니다. sshd는 SSH 프로토콜을 통해 시스템에 대한 보안 원격 액세스를 제공합니다. 구성이 잘못되었거나 실행되고 있지 않으면 SSH를 통해 VM에 연결할 수 없습니다.

이 문제를 해결하려면 Windows Server 및 Windows용 OpenSSH 서버 구성을 검토하여 sshd가 올바르게 설정되었는지 확인합니다.

연결 시간 초과

SSH 연결 타임아웃은 다음 중 하나로 인해 발생할 수 있습니다.

VM에서 부팅을 완료하지 않았습니다. VM이 부팅될 때까지 잠시 기다립니다.

이 문제를 해결하려면 VM이 부팅을 끝낼 때까지 기다린 다음 다시 연결을 시도합니다.
SSH 패키지가 설치되지 않았습니다. SSH를 사용하여 연결하려면 Windows VM에 google-compute-engine-ssh 패키지를 설치해야 합니다.

이 문제를 해결하려면 SSH 패키지를 설치합니다.

실패한 SSH 연결 진단

다음 섹션에서는 실패한 SSH 연결의 원인을 진단하기 위한 단계와 연결을 수정하기 위한 단계를 설명합니다.

실패한 SSH 연결을 진단하기 전에 다음 단계를 완료합니다.

최신 버전의 Google Cloud CLI를 설치하거나 업데이트합니다.
연결 테스트를 실행합니다.
게스트 환경을 실행하지 않는 커스텀 Linux 이미지를 사용 중이면 Linux 게스트 환경을 설치합니다.
OS 로그인을 사용하는 경우 OS 로그인 문제 해결을 참조하세요.

Linux 및 Windows VM 진단 방법

연결 테스트

방화벽, 네트워크 연결 또는 사용자 계정과 관련된 연결 문제로 인해 SSH를 통한 VM 인스턴스 연결이 불가능할 수 있습니다. 어떤 연결 문제가 있는지 확인하려면 이 섹션의 단계를 따르세요.

방화벽 규칙 확인

Compute Engine은 각 프로젝트에 SSH 트래픽을 허용하는 기본 방화벽 규칙 집합을 프로비저닝합니다. 인스턴스에 액세스할 수 없는 경우 gcloud compute 명령줄 도구를 사용하여 방화벽 목록을 확인하고 default-allow-ssh 규칙이 있는지 확인합니다.

로컬 워크스테이션에서 다음 명령어를 실행하세요.

gcloud compute firewall-rules list

방화벽 규칙이 없으면 다시 추가합니다.

gcloud compute firewall-rules create default-allow-ssh \
    --allow tcp:22

프로젝트의 default-allow-ssh 방화벽 규칙과 관련된 모든 데이터를 보려면 gcloud compute firewall-rules describe 명령어를 사용합니다.

gcloud compute firewall-rules describe default-allow-ssh \
    --project=project-id

방화벽 규칙에 대한 자세한 내용은 Google Cloud의 방화벽 규칙을 참조하세요.

네트워크 연결 테스트

네트워크 연결이 작동하는지 확인하려면 TCP 핸드셰이크를 테스트합니다.

VM에 대한 외부 natIP를 가져옵니다.
```
gcloud compute instances describe VM_NAME \
    --format='get(networkInterfaces[0].accessConfigs[0].natIP)'
```
VM_NAME을 연결할 수 없는 VM의 이름으로 바꿉니다.

참고: IAP를 사용하여 내부 IP 주소를 통해 인스턴스에 액세스하는 경우 IP 주소가 다를 수 있습니다. 또한 IP 주소가 내부 주소이면 VPC 네트워크 내에서만 인스턴스에 액세스할 수 있습니다.

워크스테이션에서 VM에 대한 네트워크 연결을 테스트합니다.

Linux, Windows 2019/2022, macOS

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

다음을 바꿉니다.

EXTERNAL_IP: 이전 단계에서 가져온 외부 IP 주소입니다.
PORT_NUMBER: 포트 번호입니다.

TCP 핸드셰이크가 성공하면 출력은 다음과 비슷합니다.

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

Connected to 행은 성공적인 TCP 핸드셰이크를 나타냅니다.

Windows 2012 및 2016

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

다음을 바꿉니다.

EXTERNAL_IP: 이전 단계에서 가져온 외부 IP입니다.
PORT_NUMBER: 포트 번호입니다.

TCP 핸드셰이크가 성공하면 출력은 다음과 비슷합니다.

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

Connected: True 행은 성공적인 TCP 핸드셰이크를 나타냅니다.

TCP 핸드셰이크가 성공적으로 완료되면 소프트웨어 방화벽 규칙이 연결을 차단하지 않고 OS가 패킷을 올바르게 전달하며 서버가 대상 포트에서 리슨합니다. TCP 핸드셰이크가 성공적으로 완료되었지만 VM이 SSH 연결을 수락하지 않으면 sshd 데몬이 잘못 구성되었거나 올바르게 실행되지 않았을 수 있습니다. 사용 중인 운영체제의 사용자 가이드를 검토하여 sshd_config가 올바르게 설정되었는지 확인합니다.

두 VM 간 VPC 네트워크 경로 구성을 분석하기 위해 연결 테스트를 실행하고 프로그래밍된 구성이 트래픽을 허용해야 하는지 확인하려면 Google Cloud에서 잘못 구성된 방화벽 규칙 확인을 참조하세요.

다른 사용자로 연결

로그인이 안 되는 문제는 사용자 계정에 국한된 문제일 수 있습니다. 예를 들어 인스턴스의 ~/.ssh/authorized_keys 파일에 대한 권한이 사용자에게 올바르게 설정되어 있지 않을 수 있습니다.

SSH 요청으로 ANOTHER_USERNAME을 지정하여 gcloud CLI를 사용하여 다른 사용자로 로그인을 시도하세요. gcloud CLI는 프로젝트의 메타데이터를 업데이트하여 신규 사용자를 추가하고 SSH 액세스를 허용합니다.

gcloud compute ssh ANOTHER_USERNAME@VM_NAME

다음을 바꿉니다.

ANOTHER_USERNAME은 사용자의 고유 사용자 이름과 다른 사용자 이름입니다.
VM_NAME은 연결하려는 VM의 이름입니다.

직렬 콘솔을 사용한 문제 디버그

직렬 콘솔의 로그에서 연결 오류를 검토하는 것이 좋습니다. 브라우저를 사용하여 로컬 워크스테이션에서 루트 사용자로 직렬 콘솔에 액세스할 수 있습니다. 이 방법은 SSH로 로그인할 수 없거나 인스턴스에 네트워크 연결이 없는 경우 유용합니다. 직렬 콘솔은 두 경우 모두에서 액세스 가능한 상태로 유지됩니다.

VM의 직렬 콘솔에 로그인하고 VM의 문제를 해결하려면 다음 단계를 따르세요.

VM의 직렬 콘솔에 대한 대화형 액세스를 사용 설정합니다.
Linux VM의 경우 루트 비밀번호를 수정하고 VM에 다음 시작 스크립트를 추가하세요.
```
echo root:PASSWORD | chpasswd
```
PASSWORD를 원하는 비밀번호로 바꿉니다.
직렬 콘솔을 사용하여 VM에 연결합니다.
Linux VM의 경우 모든 오류 디버깅을 완료한 후 루트 계정 로그인을 중지합니다.
```
sudo passwd -l root
```

Linux VM 진단 방법

VM 인스턴스를 종료하지 않은 상태로 검사

연결할 수 없는 인스턴스에서 계속해서 올바른 프로덕션 트래픽을 제공하는 경우가 있습니다. 이 경우에는 인스턴스를 중단하지 않은 상태에서 디스크를 검사해야 합니다.

디스크를 검사하고 문제를 해결하려면 다음 안내를 따르세요.

디스크 스냅샷을 만들어 부팅 디스크를 백업합니다.
이 스냅샷에서 일반 영구 디스크를 만듭니다.
임시 인스턴스를 만듭니다.
일반 영구 디스크를 새로운 임시 인스턴스에 연결하고 마운트합니다.

이 절차에서는 SSH 연결만 허용하는 격리된 네트워크를 만듭니다. 이 설정은 복제된 인스턴스가 프로덕션 서비스에 방해가 되는 결과가 발생하지 않도록 합니다.

클론된 인스턴스를 호스팅하는 새 VPC 네트워크를 만듭니다.
```
gcloud compute networks create debug-network
```
NETWORK_NAME을 새 네트워크를 호출할 이름으로 바꿉니다.

SSH를 통한 네트워크 연결을 허용하는 방화벽 규칙을 추가합니다.

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

부팅 디스크의 스냅샷을 만듭니다.
```
gcloud compute disks snapshot BOOT_DISK_NAME \
   --snapshot-names debug-disk-snapshot
```
BOOT_DISK_NAME을 부팅 디스크의 이름으로 바꿉니다.

방금 만든 스냅샷으로 새 디스크를 만듭니다.

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

외부 IP 주소 없이 새 디버깅 인스턴스를 만듭니다

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

디버깅 디스크를 인스턴스에 연결합니다.

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

안내에 따라 배스천 호스트를 사용하여 VM에 연결합니다.
디버거 인스턴스에 로그인한 후 인스턴스 문제를 해결합니다. 예를 들어 다음과 같이 인스턴스 로그를 살펴볼 수 있습니다.
```
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
```
VM_NAME을 연결할 수 없는 VM의 이름으로 바꿉니다.

시작 스크립트 사용

앞의 방법을 사용해도 문제가 해결되지 않으면 시작 스크립트를 만들어 인스턴스 시작 직후 정보를 수집할 수 있습니다. 시작 스크립트 실행에 대한 안내를 따릅니다.

이후 메타데이터가 적용되기 전에 gcloud compute instances reset을 사용하여 인스턴스를 재설정해야 합니다.

또는 진단 시작 스크립트를 실행하여 인스턴스를 다시 만들 수도 있습니다.

--keep-disks 플래그로 gcloud compute instances delete를 실행합니다.
```
gcloud compute instances delete VM_NAME \
   --keep-disks boot
```
VM_NAME을 연결할 수 없는 VM의 이름으로 바꿉니다.
동일한 디스크의 새 인스턴스를 추가하고 시작 스크립트를 지정합니다.
```
gcloud compute instances create NEW_VM_NAME \
   --disk name=BOOT_DISK_NAME,boot=yes \
   --metadata startup-script-url URL
```
다음을 바꿉니다.
- NEW_VM_NAME은 만들려는 새 VM의 이름입니다.
- BOOT_DISK_NAME은 연결할 수 없는 VM의 부팅 디스크 이름입니다.
- URL은 스크립트의 Cloud Storage URL이며 gs://BUCKET/FILE 또는 https://storage.googleapis.com/BUCKET/FILE 형식입니다.

새 인스턴스에서 디스크 사용

영구 부팅 디스크에서 데이터를 복구해야 하는 경우에는 부팅 디스크를 분리한 다음 이 디스크를 새 인스턴스의 보조 디스크로 연결할 수 있습니다.

연결할 수 없는 VM을 삭제하고 부팅 디스크는 유지합니다.
```
gcloud compute instances delete VM_NAME \
   --keep-disks=boot 
```
VM_NAME을 연결할 수 없는 VM의 이름으로 바꿉니다.
이전 VM의 부팅 디스크를 사용하여 새 VM을 만듭니다. 방금 삭제한 VM의 부팅 디스크 이름을 지정합니다.
SSH를 사용하여 새 VM에 연결합니다.
```
gcloud compute ssh NEW_VM_NAME
```
NEW_VM_NAME을 새 VM의 이름으로 바꿉니다.

VM 부팅 디스크가 가득 찼는지 확인

부팅 디스크가 가득 차면 VM에 액세스할 수 없게 될 수 있습니다. 이 시나리오는 부팅 디스크가 가득 차서 VM 연결 문제가 발생했는지 항상 명확하지는 않기 때문에 문제 해결이 어려울 수 있습니다. 이 시나리오에 대한 자세한 내용은 부팅 디스크가 가득 차서 액세스할 수 없는 VM 문제 해결을 참조하세요.

Windows VM 진단 방법

SSH 메타데이터 재설정

SSH를 사용하여 Windows VM에 연결할 수 없으면 enable-windows-ssh 메타데이터 키를 설정 해제하고 Windows용 SSH를 다시 사용 설정합니다.

enable-windows-ssh 메타데이터 키를 FALSE로 설정합니다. 메타데이터를 설정하는 방법은 커스텀 메타데이터 설정을 참조하세요.

변경사항이 적용될 때까지 몇 초 간 기다립니다.
Windows용 SSH를 다시 사용 설정합니다.
VM에 다시 연결합니다.

RDP를 사용하여 VM에 연결

Windows VM에 대한 SSH 연결 실패 원인을 진단하고 해결할 수 없으면 RDP를 사용하여 연결합니다.

VM에 연결을 설정한 후 OpenSSH 로그를 검토합니다.

다음 단계

Compute Engine에서 Linux VM에 대한 SSH 연결 작동 방법 알아보기

SSH 오류 문제 해결

SSH 문제 해결 도구

문제 해결 도구 실행

이 태스크에 필요한 권한

콘솔

gcloud

결과 검토

일반적인 SSH 오류

브라우저에서 SSH를 통해 연결 오류

승인되지 않은 오류 401

연결할 수 없음. 다시 시도하는 중...

Linux 오류

권한 거부됨(공개 키)

소유권

권한

소유권

권한

연결 실패

소유권

권한

예기치 않은 오류

소유권

권한

백엔드에 연결할 수 없음

호스트 키가 일치하지 않음

메타데이터 값이 너무 큼

Windows 오류

권한 거부됨. 다시 시도해 주세요

권한 거부됨(공개 키, 키보드 대화형)

인스턴스에 SSH를 통해 연결할 수 없음

연결 시간 초과

실패한 SSH 연결 진단

Linux 및 Windows VM 진단 방법

연결 테스트

방화벽 규칙 확인

네트워크 연결 테스트

Linux, Windows 2019/2022, macOS

Windows 2012 및 2016

다른 사용자로 연결

직렬 콘솔을 사용한 문제 디버그

Linux VM 진단 방법

VM 인스턴스를 종료하지 않은 상태로 검사

시작 스크립트 사용

새 인스턴스에서 디스크 사용

VM 부팅 디스크가 가득 찼는지 확인

Windows VM 진단 방법

SSH 메타데이터 재설정

RDP를 사용하여 VM에 연결

다음 단계